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ABSTRACT 


The  design  and  implementation  of  a  real  time  operating  system 
kernel  for  a  fault  tolerant  microcomputer  is  presented.  The  operating 
system  is  designed  for  a  real  time  imbedded  system.  The  particular  design 
is  for  a  Motorola  MC68000  microprocessor,  however,  the  majority  of  the 
operating  system  is  implemented  using  the  C  programming  language  for 
portability  to  other  microprocessors.  The  C  source  for  the  kernel  is 
presented.  The  source  code  is  modular  so  that  it  may  be  used  in  part  or  as  a 
whole  operating  system  kernel.  A  heap  implementation  of  a  priority  ready 
queue  is  used  for  task  management.  Performance  measurements  are 
included  for  parts  of  the  ready  queue. 
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THESIS  DISCLAIMER 


The  reader  is  cautioned  that  computer  programs  developed  in  this 
research  may  not  have  been  exercised  for  all  cases  of  interest.  While  every 
effort  has  been  made,  within  the  time  available,  to  ensure  that  the 
programs  are  free  of  errors,  they  cannot  be  considered  validated.  Any 
application  of  these  programs  without  additional  verification  is  at  the  risk 
of  the  user. 
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I.  INTRODUCTION 


A.  BACKGROUND 

The  topic  of  this  thesis  is  the  design  of  a  kernel  for  a  real  time  operating 
system  for  a  fault  tolerant  microcomputer  system.  The  kernel  of  the 
operating  system  is  the  portion  which  contains  some  of  the  most  intensely 
used  code.  A  real  time  operating  system,  in  the  most  general  sense,  is  a 
system  which  responds  to  events  in  real  time.  Using  this  general 
description,  most  microcomputers  and  some  minicomputers  would  fall  into 
this  category.  For  the  purpose  of  this  thesis,  a  real  time  system  is  one 
which  does  not  require  human  intervention,  other  than  to  supply  start-up 
power,  to  operate  and  has  an  operating  system  able  to  operate  within  fairly 
severe  time  constraints.  The  operating  system  must  be  able  perform  its 
task  scheduling  on  a  regular  clocked  interval,  must  be  able  to  respond  to 
outside  stimulus,  and  must  be  capable  of  dealing  with  these  functions  in 
real  time.  The  operating  system  should  be  capable  of  fully  supporting  all 
normal  supervisory  functions. 

A  second  major  feature  of  this  operating  system  is  that  it  is  designed  for 
a  fault  tolerant  environment.  A  fault  tolerant  system  is  able  to  continue  to 
provide  critical  functions  after  the  occurrence  of  a  fault.  [Ref.  1  :  p.  6]  To 
reduce  or  eliminate  generic  software  faults,  each  module  is  exhaustively 
tested.  Several  methods  are  available  for  protecting  against  generic 
software  faults,  including  recovery  blocks  and,  more  controversially,  N 
version  programming,  but  exhaustive  testing  has  been  the  only  method  to 
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prove  effective  to  date.  Tests  are  also  run  after  the  software  has  been 
integrated  into  the  system  to  show  that  the  data  flow  between  modules  is 
correct.  [Ref  2  :  p.  78] 

B.  MOTIVATION  FOR  FAULT  TOLERANT  SYSTEMS 

The  demand  for  fault  tolerant  computers  is  not  new.  The  fact  that  the 
cost  of  microprocessors  has  dropped  dramatically  in  the  past  few  years  has 
lead  to  new  avenues  of  achieving  fault  tolerance  in  computing  systems.  The 
computing  power  of  today's  thirty  two  bit  microprocessors,  coupled  with 
floating  point  co-processors,  is  quickly  surpassing  the  computational  power 
of  earlier  computers  many  times  the  compact  size  of  these  new  micro¬ 
computer  systems.  Hardware  fault  tolerance  can  now  be  achieved 
inexpensivley  through  redundancy  without  sacrificing  the  speed  and 
computing  power  of  a  larger  system.  Microprocessors  also  consume 
substantially  less  power  which  in  turn  leads  to  a  solution  for  many  of  the 
heat  problems  found  in  older  computing  systems. 

There  is  a  wide  range  of  possible  applications  for  a  compact,  low  power, 
inexpensive  fault  tolerant  computing  system.  One  obvious  example  is  the 
use  of  computers  in  any  environment  where  the  processor  will  be  isolated 
from  human  intervention  for  long  periods  of  time  as  in  just  about  any  space 
related  application.  Another  use  for  fault  tolerant,  compact  computers  is  in 
digital  fly-by-wire  advanced  flight  control  systems.  Any  situation  where  the 
capability  to  recover  from  a  non-catastrophic  fault  is  desired  is  a  possible 
application  for  a  fault  tolerant  computer. 
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The  operating  system  in  this  thesis  is  designed  for  the  fault  tolerant, 
real  time  environment  discussed  above.  An  operating  system  designed  for 
the  real  time  non-interactive  computing  system  has  many  advantages  over 
the  real  time  interactive  system.  One  major  advantage  is  the  elimination  of 
a  major  source  of  error,  human  intervention.  The  operating  system  is  a 
static  process  system  in  that  processes  are  not  created  or  disposed  of 
dynamically.  All  the  processes  the  operating  system  will  ever  need  have 
already  been  created  and  tested  before  the  computer  system  is  expected  to 
function  at  full  capacity. 

The  non-interactive  real  time  operating  system  also  has  time 
constraints  not  normally  associated  with  an  interactive  operating  system. 
The  operating  system  is  an  interrupt  driven  system  which  runs  in  a  series 
of  time  slices  called  minor  cycles.  The  minor  cycle,  approximately  twenty 
milliseconds  long  for  a  flight  control  application,  is  the  smallest  period  of 
time  in  which  the  processor  must  accomplish  basic  program  functions.  For 
example,  in  the  case  of  a  computer  system  running  a  flight  control 
application,  the  minor  cycle  is  determined  by  the  frequency  requirements  of 
the  flight  control  laws  needed  to  fly  the  aircraft. 

The  microprocessor  is  interrupted  every  twenty  milliseconds  to  signal 
the  beginning  of  a  new  minor  cycle  and  to  tell  the  operating  system  that  it  is 
time  to  schedule  a  new  batch  of  jobs  to  be  completed  during  that  minor 
cycle.  Those  jobs  that  are  not  completed  during  the  minor  cycle  that  they 
were  scheduled  in  are  put  back  in  a  ready  queue  to  wait  for  execution  or 
completion  if  a  job  was  interrupted  during  its  execution.  One  large  process 
may  be  scheduled  over  several  minor  cycles,  forming  a  major  cycle. 
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It  may  be  important  to  have  a  job  done  during  a  particular  minor  cycle 
or  not  at  all.  If  a  job  is  time  critical  and  cannot  be  completed  during  the 
minor  cycle  it  was  scheduled  in,  it  is  removed  from  the  ready  queue  without 
execution.  In  order  to  decide  what  jobs  are  to  be  done  and  in  what  order,  a 
priority  is  assigned  to  each  job.  The  operating  system  designed  in  this 
thesis  uses  static  priority  assignment.  The  priorities  never  change.  In  a 
real  time  system  where  all  the  possible  tasks  to  be  accomplished  are  known 
in  advance,  a  static  priority  assignment  is  the  most  efficient  means  of 
dealing  with  prioritized  jobs. 

The  operating  system  designed  to  operate  in  an  autonomous 
environment  requires  fault  tolerance  to  continue  running  without  outside 
help.  The  operating  system  may  run  for  several  thousand  or  several  million 
minor  cycles  before  the  computer  host  is  shut  down.  During  the  time  the 
computer  system  is  running,  the  operating  system  is  completely  self 
sufficient.  The  operating  system  can  schedule  the  necessary  tasks  and 
keep  track  of  resources  without  external  intervention  except  for  incoming 
data.  In  addition,  the  operating  system  must  be  able  to  respond  to  external 
data  inputs  and  requests  in  real  time.  The  operating  system  in  this  thesis  is 
designed  to  operate  within  the  fault  tolerant  environment. 

C.  CHOICE  OF  HARDWARE 

An  objective  of  this  thesis  is  the  implementation  of  the  operating  system 
on  a  commercially  available  microprocessor.  The  two  families  of 
microprocessors  that  were  considered  for  the  implementation  of  the 
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operating  system  were  the  National  Semiconductor  NS32000  series  and  the 
Motorola  MC68000  series  microprocessors. 

The  microprocessor  that  was  originally  chosen  for  the  project  was  the 
National  Semiconductor  NS32016  16  bit  microprocessor.  The  NS32016 
microprocessor  was  chosen  primarily  due  to  the  simplicity  and  elegance  of 
the  processor  design  and  the  direct  support  of  a  floating  point  co-processor, 
National  Semiconductor's  NS32081.  However,  second  sourcing  agreements 
have  have  not  been  productive  and  the  NS32000  chip  set  has  failed  to  achieve 
a  market  share  that  would  guarantee  that  it  will  be  supported  in  the  future. 
While  the  lack  of  attention  for  the  NS32000  family  may  make  the  costs  of 
using  the  NS32016  attractive,  the  lack  of  interest  also  means  a  lack  of 
support  in  the  critical  areas  of  peripheral  chip  manufacturing  by  second 
party  vendors  and  the  lack  of  low  power  Complementary  Metal  Oxide 
Silicon  (CMOS)  chip  sets  being  released  and  supported.  The  decision  was 
made  to  use  the  more  popular  Motorola  MC68000  microprocessor. 

The  MC68000  has  proven  to  be  a  reliable  microprocessor  for  use  in 
many  of  today's  microcomputers.  The  support  for  the  MC68000  has  helped 
to  decrease  its  cost  while  time  in  service  continues  to  prove  that  the 
MC68000  is  a  tried  and  true  microprocessor.  The  MC68000  is  readily 
available  in  CMOS  but  it  does  not  have  the  direct  support  of  a  floating  point 
unit.  Even  with  the  drawback  of  not  having  the  floating  point  unit,  the 
MC68000  appears  to  be  the  best  choice  for  a  mix  of  efficiency  and 
effectiveness.  The  overall  goal  is  to  link  several  MC68000  microprocessor 
systems  together  and,  through  redundancy,  achieve  ultra-reliability  in  the 
overall  system. 
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D.  OUTLINE  OF  THE  DESIGN  APPROACH 

Chapter  II  of  this  thesis  is  used  to  explain  the  concepts  used  in  the 
design  of  the  operating  system  and  to  provide  a  general  overview  of  the 
main  modules  which  make  up  the  kernel  of  the  operating  system. 

Chapter  III  details  the  implementation  of  the  operating  system  using  a 
Pascal-like  pseudocode  as  a  program  design  language.  Each  module  is 
discussed  in  more  detail. 

Chapter  IV  describes  the  performance  measurements  obtained  in  the 
implementation  of  the  operating  system  on  a  microcomputer.  Each  module 
is  compared  in  a  relative  manner,  realizing  that  the  hardware  used  to  test 
the  system  is  not  ideal. 

Chapter  V  presents  the  conclusions  and  recommendations  for  further 
research  in  this  area. 
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II.  CONCEPTS 


A.  BACKGROUND 

An  operating  system  of  some  form  or  another  is  required  for  any 
computer  system.  Because  most  fault  tolerant  computer  designs  have  been 
custom  designs  with  little  or  no  general  purpose  use  and  limited  market 
share,  no  ad  hoc  or  sanctioned  standard  for  operating  systems  has 
surfaced.  The  operating  system  designed  for  this  project  will  be  of  a  more 
portable  nature  such  that  the  operating  system  can  be  used  in  other 
systems.  To  achieve  the  portability  goal,  the  "C"  programming  language, 
which  is  regarded  as  portable,  was  chosen  for  a  majority  of  the  operating 
system  code. 

The  complexity  of  the  computer  hardware  need  not  be  reflected  in  the 
operating  system.  In  the  case  of  a  fault  tolerant  design,  simplicity  is 
desired  in  both  hardware  and  software.  An  objective  of  this  thesis  is  to 
achieve  a  certain  amount  of  robustness  in  the  operating  system  design 
without  years  of  test  and  evaluation.  Another  objective  is  to  maintain  a 
degree  of  simplicity  in  a  fully  functional  operating  system.  To  meet  all  the 
design  objectives  there  may  be  some  trade-offs  in  performance  parameters, 
such  as  speed  and  efficiency.  However,  in  order  to  maintain  real  time 
responsiveness,  there  is  little  room  for  compromise  in  speed.  The  ability  to 
be  diverse  and  flexible  is  also  desired.  The  sum  of  all  these  qualities:  speed, 
efficiency,  robustness  ,  diversity,  and  simplicity  should  create  a  satisfactory 
overall  performance  in  the  operating  system. 


16 


Central  to  the  concept  of  a  real-time  operating  system  is  the  ability  of  the 
computer  system  to  respond  to  the  randomness  of  the  external  world.  To 
respond  to  these  random  external  inputs  the  system  needs  to  be  able  to 
remove  some  of  the  uncertainty  which  arises  from  these  independent 
events  and  to  stabilize  the  situation  so  that  the  process  can  be  performed  in 
an  orderly  fashion.  The  method  by  which  random  externals  are  stabilized 
and  organized  is  to  prioritize  the  events  and  to  schedule  and  process  these 
events  with  respect  to  each  events'  pre-assigned  priority.  Because  a  single 
CPU  is  only  capable  of  processing  one  function  at  a  time,  there  must  be  a 
great  deal  of  flexibility  in  the  system  to  deal  with  random  events  in  addition 
to  the  regularly  scheduled  tasks. 

B.  OVERVIEW 

The  operating  system  in  a  real  time  environment  is  the  manager  of  all 
hardware  and  software  functions.  The  operating  system  can  be  thought  of 
as  multiple  levels  of  distinct  functional  layers.  The  hardware  itself  forms 
the  base  layer.  The  kernel  is  the  only  level  that  has  a  direct  interface  with 
the  hardware  and  has  the  highest  software  priority.  The  supervisor  level  is 
the  level  which  usually  supports  the  user  level  by  making  requests  of  the 
kernel  and  providing  some  supervisory  services  to  the  user  level.  The  user 
processes  form  the  user  level  and  are  the  lowest  priority  processes.  Because 
each  level  represents  a  higher  priority,  a  hierarchy  is  formed.  Such 
hierarchal  designs  have  proven  easier  to  debug,  modify  and  to  prove 
correct.  [Ref.  3  :  pp.  341-346]  The  hierarchy  of  a  typical  operating  system  is 
illustrated  in  Figure  2.1. 
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User  Tasks,  Run  Time  Libraries 


Scheduling,  I/O,  Interrupt  Handling, 
Memory  Management,  System  Services 


Figure  2.1  Operating  System  Hierarchy 
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This  thesis  is  concerned  mainly  with  the  kernel  level  of  the  operating 
system.  The  user  level  in  a  real  time  imbedded  system,  such  as  the  system 
that  this  operating  system  is  designed  for,  rarely  has  a  need  for  user  level 
services  as  they  are  defined  in  real  time  interactive  systems.  The  user 
processes  in  an  imbedded  system  can  be  thought  of  as  system  level 
processes  and  thus  help  to  simplify  the  design  by  giving  all  processes  direct 
access  to  the  kernel. 

The  kernel  is  responsible  for  the  following  functions  in  a  real-time 
operating  system.  [Ref.  4  :  p.  65] 

*  Interrupt  handling 

*  Task  scheduling 

*  Task  switching 

*  Task  suspension  and  resumption 

*  Support  of  Input/Output  activities 

*  Support  of  memory  management  functions 

*  Support  of  a  file  system 

The  operating  system  designed  in  this  thesis  has  fewer  capabilities 
than  those  described  above.  There  is  no  need  for  the  support  of  a  file 
system.  There  is  no  need  for  the  support  of  memory  management  functions 
since  each  processor  has  its  own  memory  that  is  shared  globally  between 
the  operating  system's  processes  with  no  dynamic  memory  allocations.  The 
major  functions  performed  by  the  operating  system  developed  here  are  the 
task  scheduling,  suspension,  resumption,  switching  and  interrupt 
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handling.  Interrupt  handling  is  the  most  important  because  the  operating 
system  is  an  interrupt  driven  system. 

A  general  state  diagram  listing  the  major  functions  of  the  operating 
system  is  shown  in  Figure  2.2.  Each  state  or  module  will  be  discussed  in 
more  detail.  As  shown  in  the  diagram,  each  state  is  a  separate  software 
module  written  primarily  in  the  "C"  programming  language.  The 
modularity  of  the  operating  system  enhances  its  portability  to  other  systems 
either  in  part  or  as  a  complete  operating  system. 

C.  THE  CENTRAL  TASK  PROCESSOR 

In  order  to  reliably  deal  with  the  variety  of  inputs  in  the  real-time  system 
described  in  this  thesis  and  to  maintain  simplicity  in  the  design,  it  was 
decided  to  use  a  Central  Task  Processor  through  which  all  jobs  would  be 
processed.  Each  job  or  routine  is  assigned  its  own  "instruction"  which 
must  be  decoded  prior  to  execution.  The  only  exceptions  to  this  rule  are 
catastrophic  error  handling  routines  and  non-maskable  interrupts.  The 
non-maskable  interrupt  routines  are  processed  without  maintaining  the 
system  status  because  of  the  serious  conditions  under  which  a  non¬ 
maskable  interrupt  can  be  expected  to  occur  usually  means  that  the  system 
will  need  to  be  reset. 

In  this  design,  the  Central  Task  Processor  uses  the  unimplemented 
instruction  of  the  Motorola  MC68000  microprocessor  known  as  the  "A-Line" 
trap.  It  is  called  the  A-Line  trap  because  the  instruction,  which  is  a  one 
word  value,  always  begins  with  a  hexidecimal  "A"  in  the  first  four  bits.  By 
assigning  each  task  a  different  A-Line  value  in  the  last  12  bits  of  the  A-Line 
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word,  every  process  is  defined  by  a  one  word  value.  This  idea  could  be 
implemented  on  other  microprocessors  by  the  use  of  a  trap  style 
instruction,  however,  the  flexibility  and  the  large  number  of  tasks  that 
could  be  described  in  a  single  word  made  this  an  obvious  advantage  for  the 
MC68000. 

D.  THE  TASK  SCHEDULER 

The  Task  Scheduler  is  responsible  for  the  scheduling  of  tasks  at  the 
beginning  of  each  minor  cycle.  The  operating  system  is  responsible  for  the 
execution  of  a  sequence  of  minor  cycles,  which  are  initiated  by  a  timer 
interrupt  generated  within  the  computer  system.  The  timer  interrupt 
causes  the  operating  system  to  suspend  the  task  that  is  being  executed  and 
to  start  the  execution  of  a  new  minor  cycle.  The  first  thing  that  happens  in 
a  new  minor  cycle  is  to  save  the  state  of  the  suspended  job  and  begin 
scheduling  a  new  set  of  jobs  based  on  the  frame  number  of  the  new  minor 
cycle.  The  frame  number  is  maintained  by  the  frame  counter  which  is  a 
thirty  two  bit  quantity  which  has  been  initialized  to  zero  during  the  start-up 
phase.  It  is  the  Task  Scheduler's  job  to  insure  that  the  frame  counter  for 
the  system  is  incremented.  For  aircraft  controls,  the  typical  time  for  a 
minor  cycle  is  ten  to  twenty  milliseconds.  For  example,  twenty  milliseconds 
was  used  in  the  Digital  Fly-By-Wire  Flight  Control  Validation  Experience 
for  the  F-8  aircraft  using  an  AP-101  computer.  This  twenty  millisecond 
time  for  a  minor  cycle  can  be  varied  for  experimental  purposes  and  should 
be  adjusted  to  be  a  suitable  amount  of  time  for  the  program  functions  to  be 
accomplished.  Some  functions  do  not  have  to  be  completed  in  a  single 
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minor  cycle  but  require  several  minor  cycles  forming  a  major  cycle. 

[Ref.  1  :  pp.  95-96]  Figure  2.3  illustrates  the  sequence  of  execution  of  a 
minor  cycle. 

A  desired  feature  of  the  operating  system  is  the  ability  to  distribute  the 
tasks  evenly  among  the  minor  cycles  so  as  to  make  better  use  of  the 
processor  throughput.  The  jobs  are  scheduled  according  to  their  sample 
time  requirements,  and  normally  must  be  completed  in  the  cycle  they  are 
originally  scheduled  in.  Certain  jobs  are  scheduled  every  cycle  while  some 
may  be  scheduled  every  other  or  every  fourth  cycle.  The  jobs  which  must  be 
completed  during  the  cycle  in  which  they  are  scheduled  will  be  marked  so 
that  if  a  job  does  not  complete  execution  during  the  minor  cycle  in  which  it 
was  originally  scheduled,  the  job  will  be  purged  from  the  Ready  Queue  at 
the  end  of  the  current  minor  cycle. 

There  will  be  a  requirement  to  indicate  which  jobs  have  been  purged 
from  the  Ready  Queue,  especially  in  the  final  determination  of  the  length  of 
the  minor  cycle.  The  possibility  exists  that  a  job  may  not  be  executed  until 
the  frame  counter  has  turned  over  and  is  on  the  same  frame  number 
again,  however,  with  a  thirty  two  bit  frame  counter,  this  job  would  prove  to 
be  delayed  4,294,967,296  times.  Assuming  a  twenty  millisecond  minor 
cycle,  a  job  would  have  to  be  delayed  994.2  days  or  2.724  years.  This  is  an 
acceptable  risk. 

E.  THE  READY  QUEUE 

The  heart  of  the  operating  system  kernel  lies  in  the  two  most  important 
functions  of  the  Ready  Queue  and  the  Task  Scheduler.  The  major 
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Figure  2.3  Minor  Cycle  Timing  Sequence 
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requirements  for  these  two  critical  areas  are  speed  and  efficiency.  A  major 
percentage  of  all  the  code  executed  by  the  system  lies  in  the  maintenance  of 
the  Ready  Queue.  The  Ready  Queue  is  described  by  a  binary  tree  data 
structure  known  as  a  heap.  A  heap  is  implemented  using  a  sequential 
representation  based  on  an  array.  The  array  elements  form  a  complete 
binary  tree  such  that  each  parent  is  less  than  either  of  its  children.  In  order 
to  achieve  a  maximum  speed  and  efficiency  the  Ready  Queue  was  designed 
as  a  heap  implementation  of  a  priority  queue. 

There  are  several  means  of  implementing  a  priority  queue.  The  major 
reason  for  choosing  a  heap  implementation  is  that  it  is  the  most  efficient 
method  for  a  non-trivial  number  of  elements  in  the  queue  for  the  two 
critical  queue  operations  of  enqueueing  and  dequeueing.  Figure  2.4 
summarizes  three  types  of  queues  and  the  approximate  orders  of 
magnitude  for  a  single  insertion  and  deletion  in  each  type  of  queue. 
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n) 

Figure  2.4  Performance  Estimates  of  Priority  Queues  [Ref.  5  :  p.  108] 

Figure  2.5  illustrates  graphically  the  relative  orders  of  magnitude 
differences  between  the  List  and  Heap  priority  queues.  The  lists  are  more 
efficient  at  dequeueing  but  the  heap  is  considerably  better  overall  as  the 
number  of  elements  in  the  queue,  n,  becomes  large. 
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The  Ready  Queue  is  also  capable  of  having  a  job  of  the  same  type 
scheduled  more  than  once  and  will  treat  these  on  a  first  in  first  out  basis. 
Two  jobs  will  never  actually  be  identical  since  a  serial  number  will  be 
assigned  to  the  job  as  it  enters  the  queue. 

For  purging  operations,  the  heap  implementation  is  approximately 
equivalent  to  the  list  implementation  since  the  queue  is  represented  by  an 
array  of  pointers.  The  heap  implementation  actually  has  less  housekeeping 
for  keeping  track  of  free  space  in  the  queue  than  the  list  implementation. 
Overall,  the  heap  implementation  appears  superior. 


Relative  Queue  Performances 


Figure  2.5  Relative  Orders  of  Magnitude 
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F.  THE  INTERRUPT  HANDLER 

There  are  several  interrupt  handlers  that  are  used  in  the  operation  of  an 
operating  system.  The  one  which  will  be  discussed  here  is  the  Cycle 
Interrupt  Handler.  The  Cycle  Interrupt  Handler  is  the  routine  which  is 
called  after  the  microprocessor  has  been  interrupted  for  the  beginning  of  a 
new  frame  or  minor  cycle.  Two  important  functions  that  must  be 
performed  at  the  beginning  of  a  new  frame  are  to  schedule  all  the  jobs  in 
the  queue  for  the  new  minor  cycle  and  to  purge  any  jobs  which  remain  in 
queue  but  are  no  longer  valid.  A  job  is  no  longer  valid  when  it  is  marked  as 
a  job  to  be  completed  within  the  current  minor  cycle  but  its  frame  number 
does  not  match  the  current  minor  cycle's  frame  number. 

The  Cycle  Interrupt  Handler  is  responsible  for  saving  the  status  of  the 
job  that  was  active  at  the  time  of  the  interrupt  and  to  call  the  scheduler  and 
purge  functions.  After  completing  the  scheduler  and  purge  calls,  the  Cycle 
Interrupt  Handler  returns  the  control  of  the  operating  system  back  to  the 
Central  Task  Processor.  The  Central  Task  Processor  then  will  perform  its 
function  and  activate  the  job  with  the  highest  priority. 

G.  SUMMARY 

The  basic  concepts  discussed  for  each  of  the  main  modules  of  the 
operating  system  have  been  reviewed  in  a  very  general  manner.  In  the 
next  chapter  the  implementations  will  be  discussed. 


27 


III.  IMPLEMENTATION  OF  THE  OPERATING  SYSTEM 


A.  INTRODUCTION 

In  this  chapter  the  details  of  the  implementation  will  be  discussed.  The 
main  modules,  the  Central  Task  Processor,  the  Cycle  Interrupt  Handler, 
the  Ready  Queue  and  the  Task  Scheduler  will  be  illustrated  in  a  Pascal  like 
pseudocode  and  flow  diagrams.  The  actual  "C"  code  and  assembly 
language  code  is  found  in  Appendix  A. 

In  order  to  avoid  confusion  and  to  set  up  a  basis  for  the  rest  of  the 
chapter,  some  definitions  are  provided  in  Table  3.1.  The  definitions  used  in 
this  thesis  may  not  strictly  adhere  to  definitions  used  in  the  development  of 
other  operating  system  designs  but  the  difference  occurs  only  when  a 
standard  definition  is  not  widely  accepted  as  accurate. 


TABLE  3.1  TERMS  AND  DEFINITIONS 


Term 

Definition 

A-Line 

An  A-Line  is  a  one  word  (16  bit)  value 
whose  first  4  bits  are  a  hexidecimal  "A". 

A-line  Trap 

A  feature  of  the  MC68000  microprocessor 
which  allows  an  extension  to  the  normal 

instruction  set  through  the  use  of  A-Lines. 

C 

A  general  purpose,  relatively  "low  level" 
programming  langauge. 

CTP 

The  Central  Task  Processor  through  which 
all  tasks  are  processed. 
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TABLE  3.1  -  Continued 


Term 

Definition 

Dequeue 

Removing  an  item  from  the  queue. 

Dispatch 

The  process  of  decoding  a  job  number  and 
starting  execution  the  job. 

Enqueue 

Adding  an  item  into  the  queue. 

F-Line 

An  F-Line  is  a  one  word  (16  bit)  value 
whose  first  4  bits  are  a  hexidecimal  "F". 

F-line  Trap 

A  feature  of  the  MC68000  microprocessor 
which  allows  an  extension  to  the  normal 
instruction  set  through  the  use  of  F-Lines. 

This  feature  is  reserved  for  the  addition 
of  the  MC68881  Floating  Point  Coprocessor. 

Failure 

A  condition  which  can  give  rise  to  a  fault, 
usually  considered  permanent. 

Fault 

An  anomaly  in  the  performance  of  the  system. 

Fault  Tolerant 

A  system  which  is  able  to  continue  to 
provide  critical  functions  after  the 
performance  of  a  fault. 

Interrupt 

An  external  condition  which  causes  the 
microprocessor  to  stop  execution  to 
service  a  request. 

Job 

A  specific  set  of  code  which  defines  a 
process  and  is  assigned  a  prioritized 
number.  Interchangeable  with  task. 

Kernel 

The  portion  of  the  operating  system  for  the 
control  and  management  of  all  operations 
that  involve  processes  and  resources. 
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TABLE  3.1  --  Continued 


Term 

Definition 

Major  Cycle 

An  integral  number  of  minor  cycles  needed 
to  perform  an  entire  function. 

Minor  Cycle 

The  smallest  interval  of  time  needed  to 
perform  the  basic  program  functions 

Monitor 

A  program  which  allows  the  monitoring 
and  alteration  of  the  system. 

Nucleus 

Another  term  for  kernel. 

Operating 

System 

Programs  which  allow  control  of  the 
hardware,  making  it  usable. 

Priority  Queue 

A  hierarchal  queue. 

Process 

A  program  in  execution. 

Purge 

Removal  of  a  no  longer  needed  item  from 
the  queue. 

Queue 

A  data  structure  which  contains 
information  about  processes. 

Ready  Queue 

A  queue  whose  processes  are  ready  to  be 
executed. 

Real-Time 

Operating 

System 

An  operating  system  which  responds  to 
events  as  they  occur. 

Task 

A  specific  set  of  code  which  defines  a 
process.  Interchangeable  with  job. 

Watch  Dog 
Timer 

A  timer  which  interrupts  the  system  after 
a  set  amount  of  time  has  elapsed. 
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In  addition  to  designing  the  program  structure,  the  design  of  the 
operating  system  also  includes  the  design  of  data  structures  and 
"structures"  as  defined  by  Kernighan  and  Ritchie  in  Reference  [6],  There  is 
also  the  A-Line  trap  word  which  in  itself  is  a  type  of  data  structure.  Figure 
3.1  shows  the  makeup  of  an  A-Line  word. 


Frame  Critical  Bit 

0  =  Not  Frame  Critical 
1  =  Frame  Critical 

(must  be  completed  within  frame) 

Figure  3.1  A-Line  Trap  Word 

In  this  format,  the  last  twelve  bits  of  the  word  completely  describe  a  job. 
The  information  in  the  A-Line  coupled  with  a  dispatch  table  gives  the 
location  in  Read  Only  Memory  of  the  job  to  be  executed. 

The  Ready  Queue  is  the  only  other  major  data  structure  which  needs  to 
be  explained.  The  Ready  Queue  is  a  heap  implementation  of  a  priority 
queue.  The  queue  itself  is  an  array  of  pointers  which  point  to  an  array  of 
nodes  which  hold  the  data  for  each  job  in  the  queue.  In  this  fashion  all 
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memory  for  the  queue  is  allocated  at  the  time  of  the  definition  of  these 
arrays.  Figure  3.2  shows  the  data  structures  involved  in  the  Ready  Queue. 


Ready  Queue 


Figure  3.2  Ready  Queue  Data  Structures 
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B.  SYSTEM  OVERVIEW 

The  operating  system  is  confined  to  performing  a  limited  number  of 
services.  The  reason  for  these  limitations  is  that  the  operating  system  is 
not  meant  to  be  generic  or  multi-purpose.  This  operating  system  is 
designed  to  perform  a  pre-defined  number  of  tasks  that  are  located  in  Read 
Only  Memory  (ROM)  and  are  therefore  somewhat  permanent.  The 
operating  system  itself  is  designed  to  be  ROM  resident  using  Random 
Access  Memory  for  the  dynamic  components  of  the  system  such  as  the 
Ready  Queue.  All  of  the  memory  for  the  Ready  Queue  and  the  variables 
required  by  the  tasks  is  pre-allocated  during  the  initialization  phase  of  the 
system.  By  not  allowing  any  dynamic  memory  allocations,  the  possibility  of 
a  task  overwriting  another  task's  memory  space  is  reduced.  By  eliminating 
accidental  memory  overwrites,  a  form  of  memory  protection  is  added  to  the 
fault  tolerant  capabilities  of  the  system.  The  value  of  the  memory  protection 
scheme  is  increased  because  a  priori  knowledge  exists  about  the  memory 
requirements  of  every  possible  task.  With  this  increased  certainty,  virtually 
all  memory  overwrites  can  be  eliminated. 

Figure  3.3  shows  the  basic  flow  for  the  operating  system.  Not  all  of  the 
modules  shown  were  implemented  in  "C".  There  are  some  functions, 
which  must  deal  with  hardware,  which  are  not  practical  or  convenient  to 
write  in  "C".  Some  portions  of  the  operating  system  are  executed  so 
frequently  that  it  is  preferable  to  write  these  parts  of  code  in  assembly 
language  for  execution  efficiency.  Even  the  UNIX  operating  system  kernel 
contains  1000  lines  of  assembly  code  along  with  its  10,000  lines  of  "C" 
code. [Ref.  4  :  p.  484]  Those  modules  written  strictly  in  assembly  language 


33 


Figure  3.3  General  System  Flow 
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code  were  the  A-Line  Trap  handler  and  the  main  part  of  the  Central  Task 
processor.  For  convenience,  the  portions  of  code  dealing  with  peripheral 
chip  initialization  and  support  were  also  written  in  assembly  language. 

As  shown  in  Figure  3.3,  the  heart  of  the  operating  system  lies  in  the 
Central  Task  Processor.  The  Central  Task  Processor  is  made  up  of  the  A- 
Line  Trap  handler,  and  the  Job  Dispatch  Table.  All  jobs,  whether 
previously  interrupted  or  not,  will  be  processed  by  the  Central  Task 
Processor.  While  the  Central  Task  Processor  may  be  some  of  the  most 
heavily  used  code,  it  is  not  particularly  complex  and  therefore  the  operating 
system  does  not  spend  a  large  percentage  of  time  executing  this  module. 

The  Ready  Queue,  with  all  of  its  associated  maintenance,  is  the  area 
where  the  operating  system  spends  most  of  its  time.  In  order  to  increase 
the  efficiency  of  the  operating  system  as  a  whole,  close  attention  must  be 
paid  to  the  efficiency  of  the  Ready  Queue. 

The  interrupt  handler,  denoted  as  the  Cycle  Interrupt  module  in  Figure 
3.3,  is  a  small  portion  of  code  which  is  also  written  in  assembly  language 
code.  The  interrupt  handler  is  an  additional  area  of  necessary  overhead 
which  must  be  optimized.  The  Cycle  Interrupt  module  calls  the  Task 
Scheduler  and  the  Purge  routines  which  in  turn  call  routines  that  add  to 
and  delete  from  the  Ready  Queue,  respectively. 

C.  THE  CENTRAL  TASK  PROCESSOR 

All  the  jobs  are  processed  through  the  Central  Task  Processor  to 
increase  fault  tolerance.  The  use  of  a  centralized  area  of  the  operating 
system  to  monitor  the  start  of  any  new  job  or  the  completion  of  any 
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interrupted  job  was  intended  to  help  the  operating  system  monitor  the 
system  and  thereby  increase  its  resistance  to  faults.  The  Central  Task 
Processor  includes  the  A-Line  Trap  handler  and  the  Dispatch  Table  for 
execution  of  new  jobs.  The  Central  Task  Processor  is  also  responsible  for 
the  continuation  of  old  jobs  that  have  been  previously  interrupted. 

Figure  3.4  shows  the  main  part  of  the  Central  Task  Processor  which 
was  implemented  in  assembly  language  code  to  facilitate  the  use  of  the  A- 
Line  Trap  and  the  direct  manipulation  of  registers.  The  first  task  is  the 
retrieval  of  the  job  number.  Because  the  Ready  Queue  is  a  priority  queue, 
the  next  job  to  be  executed  will  always  be  the  top  job  in  the  queue.  In  the  one 
word  A-Line  value,  which  represents  the  job  number,  bit  eleven  is  the 
interrupt  status  bit.  If  the  job  has  been  previously  started  and  interrupted 
this  bit  will  be  set. 

There  are  two  ways  in  which  a  job  can  be  executed.  First,  if  the  job  is  a 
new  job,  the  A-Line  value  will  be  loaded  into  an  address  location  to  be 
executed  as  an  unimplemented  instruction.  Second,  if  the  job  had  been 
started  and  then  interrupted,  the  microprocessor  is  restored  to  the  state  it 
had  immediately  after  the  job  was  interrupted,  and  then  a  return  from 
exception  (RTE)  instruction  is  executed. 

The  return  from  exception  instruction  will  take  the  top  six  bytes  off  the 
stack  and  resume  execution  at  the  restored  program  counter  (PC)  which 
was  stored  on  the  stack.  The  old  status  register  will  also  be  restored.  Since 
the  stack  pointer  which  is  restored  prior  to  the.execution  of  the  RTE  is 
pointing  to  the  the  status  of  the  job  when  it  was  interrupted,  execution 
continues  where  the  job  was  at  the  time  of  the  interrupt. 
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Figure  3.4  Central  Task  Processor 
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1.  A-Line  Traps 


The  routine  for  the  execution  of  a  new  job  is  to  load  the  A-Line  Trap 
into  a  pre-defined  address  so  that  it  will  be  executed  as  the  next  instruction 
after  the  load.  Once  the  program  counter  encounters  this  A-Line  the 
exception  handler  routes  execution  to  the  routine  whose  address  is  in  the 
vector  table  in  low  memory.  This  is  the  A-Line  Traps  module  whose  flow 
diagram  is  illustrated  in  Figure  3.5. 

The  first  thing  done  in  this  exception  handling  routine  is  to  inhibit 
any  other  interrupts.  Since  the  exception  handling  routine  of  the  MC68000 
has  pushed  the  status  register  and  the  program  counter  onto  the  stack  and 
there  will  not  be  a  return  from  exception  instruction  executed  from  this 
routine,  the  stack  must  be  adjusted.  The  next  thing  to  do  is  fetch  the  job 
number  that  caused  the  exception  in  the  first  place.  Based  on  that  job 
number,  the  Dispatch  routine  is  called. 

2.  Dispatch  Table 

The  Dispatch  routine  is  a  "C"  routine  which  sends  the  processor  off 
to  execute  the  job.  Up  until  and  during  execution  of  the  Dispatch  routine, 
interrupts  have  been  inhibited.  It  is  the  responsibility  of  the  job  being 
executed  to  lower  the  interrupt  priority  set  by  the  A-Line  Traps  module. 
The  pseudocode  in  Figure  3.6  illustrates  the  basic  switch  statement  used  to 
dispatch  to  the  job. 

Upon  completion  of  any  routine,  whether  it  was  interrupted  or  not, 
the  routine  must  be  removed  from  the  Ready  Queue.  The  responsibility  for 
removal  is  in  the  JobDone  routine.  The  JobDone  routine  calls  the  queue 
function,  Dequeue,  which  removes  the  top  job  from  the  Ready  Queue.  Then 
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Figure  3.5  A-Line  Trap  Handler 
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JobDone  adjusts  the  stack,  because  it  was  called  as  a  subroutine  and  will 
not  return  to  the  caller.  Control  is  then  passed  back  to  the  Central  Task 
Processor  and  The  Central  Task  Processor  then  continues  on  with  the  next 
job. 


procedure  Dispatch  /*  job  dispatch  table  */ 

begin  /*  limited  number  of  jobs  version  */ 


switch(PresentJob)  /*  based  on  job  from  A-Line  Trap  */ 
begin 

case  1: 
begin 

DoJobOne;  /  *  handle  Job  1  */ 

JobDone;  /*  After  Job  is  completed  */ 

end; 


case  2: 
begin 

DoJobTwo;  /  *  handle  Job  2  */ 

JobDone;  /*  After  Job  is  completed  */ 

end; 

end; 

end; 


Figure  3.6  Dispatch  Routine 


The  decision  to  use  A-Line  traps  in  the  operating  system  was  made 
early  on  in  the  design  phase.  The  original  idea  was  that  with  each  job 
assigned  its  own  "instruction"  a  job  could  be  very  easily  called  from 
anywhere  in  any  task’s  code  for  execution.  The  job  could  be  quickly  decoded 
and  executed  and  control  returned  to  the  calling  program  with  an  return 
from  exception  instruction.  Another  consideration  was  that  there  could  be 
a  total  of  1024  different  jobs  defined  in  one  word  values.  This  seemed  to  be 
an  advantage  over  the  limited  user  defined  traps  provided  by  the  MC68000. 
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There  are  only  192  user  defined  traps  for  the  MC68000  and  their  execution  is 
slower.  As  it  turns  out,  the  A-Line  trap  could  be  replaced  by  a  simple  table 
of  contents  eliminating  a  great  deal  of  unnecessary  exception  handling 
code.  A  table  of  contents  could  be  constructed  from  an  array  of  starting 
addresses  with  the  array  subscripts  equal  to  the  job  numbers.  The  priority 
would  still  be  encoded  in  the  job  number.  This  will  be  discussed  further  in 
the  conclusions. 

D.  THE  CYCLE  INTERRUPT  HANDLER 

The  Cycle  Interrupt  Handler  is  the  routine  which  responds  to  the 
external  signalling  of  a  new  cycle  or  start  of  a  frame.  Depending  on  the 
hardware  configuration,  the  external  interrupt  is  assigned  an  interrupt 
priority.  Based  on  this  priority,  a  vector  table  in  low  memory  points  to  the 
routine  which  handles  the  interrupt.  On  the  MC68000,  there  are  seven 
levels  of  interrupts  available.  In  the  microcomputer  that  the  operating 
system  for  this  thesis  was  developed  on,  a  Synertek  SY6522  Versatile 
Interface  Adapter  (VIA)  was  used  to  generate  a  level  one  interrupt  to  signal 
the  start  of  a  new  frame. 

Figure  3.7  illustrates  the  flow  diagram  for  the  Cycle  Interrupt  Handler. 
The  first  and  most  important  responsibility  of  the  Cycle  Interrupt  Handler 
is  to  store  the  data  and  address  registers  in  the  data  structure  for  the  job 
that  was  interrupted.  The  data  structure  will  be  the  top  job  in  the  Ready 
Queue.  After  storing  the  registers,  the  interrupt  bit  of  the  job  is  set  so  that 
the  Central  Task  Processor  will  know  that  the  interrupted  job  had  started 
execution. 
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Figure  3.7  Cycle  Interrupt  Handler 
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The  Purge  and  Task  Scheduler  routines  are  called  next.  Purge  is  a 
Ready  Queue  maintenance  routine  which  removes  the  residue  of  jobs 
which  had  to  be  executed  in  the  last  frame  from  the  Ready  Queue.  The 
Task  Scheduler  then  enqueues  all  the  new  jobs  for  the  new  frame.  Upon 
completion  of  the  Purge  and  Task  Scheduler  routines  the  Cycle  Interrupt 
Handler  returns  control  to  the  Central  Task  Processor  for  execution  of  the 
next  job. 

E.  THE  READY  QUEUE 

1.  Heap  Data  Structure 

The  Ready  Queue  is  represented  as  a  heap  implementation  of  a 
priority  queue.  A  heap  is  a  restricted  binary  tree  data  structure.  The  Ready 
Queue  is  a  sequential  array  of  pointers.  The  requirements  for  a  sequence  to 
be  a  heap  is  that  each  parent  must  be  less  than  either  of  its  children.  If  r[l], 
r[2],  ...  r[n]  is  a  sequence  of  elements,  the  sequence  is  a  heap  if  r[i]  <  r  [2i] 
and  r[i]  <  r[2i+l].  Lower  job  numbers  in  the  heap  represent  a  higher 
priority  job. 

2.  Enqueue  Routine 

The  flow  diagram  for  the  Enqueue  module  is  shown  in  Figure  3.8. 

The  Enqueue  routine  calculates  a  serial  number  to  insure  that  if  the  job  is 
added  to  the  queue  twice  in  one  frame  it  is  treated  on  a  first  in-first  out 
basis.  The  serial  number  for  each  job  is  located  in  an  array  of  serial 
numbers  indexed  by  job  number.  To  make  room  for  the  serial  number,  the 
job  number,  which  is  an  A-Line,  is  shifted  four  bits  to  the  left.  The  job  is 
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Figure  3.8  Enqueue  a  Job 
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then  assigned  the  lowest  position  in  the  queue  and  the  Siftup  routine  is 
called. 

A  simplified  Enqueue  routine  is  shown  in  Figure  3.9  using  data 
structures  and  variables  similar  to  those  used  in  the  actual  Ready  Queue. 
The  elements  are  added  to  the  queue  using  the  Enqueue  routine. 


procedure  enqueue(  A-Line  :  jobNumber) 
begin 

RQSize  =  RQSize  +  1;  /*  increase  RQ  Size  */ 

RQNode[RQSize]. JobNumber  =  jobNumber;  /*  fill  new  node  */ 

RQNode[RQSize].FrameStart  =  FrameCounter; 
siftup(RQSize);  /*  restructure  heap  */ 

end; 

Figure  3.9  Enqueue  -  Add  an  Element  to  the  Queue  [Ref.  5  :  pp.  243-245] 


3.  Siftup 

The  operation  Siftup  moves  an  element  of  the  queue  toward  the  root. 
Siftup  is  restricted  to  a  single  path  from  the  leaf  node  to  the  root  of  the  heap. 
Because  of  this  single  path,  it  will  require  at  most  0(log2  n)  effort  to  add  an 
element  to  a  queue  of  size  n.  Figure  3.10  shows  the  Siftup  routine.  The 
element  which  is  being  "sifted  up"  is  moved  from  the  location  "position" 
toward  the  root  until  the  heap  conditions  are  satisfied. 

Figure  3.11(a)  shows  a  heap  formed  from  a  sequence  of  integers.  The 
integers  in  Figure  3.11(a)  were  added  to  the  queue  in  the  following  order  : 
015,004  023,010,036.  The  numbers  alongside  the  elements  in  Figure  3.11(a) 
represent  the  array  subscripts  of  the  integer  sequence.  Figure  3.11(b)  shows 
the  heap  in  Figure  3.11(a)  after  adding  the  element  012  using  the  Enqueue 
and  Siftup  functions. 


45 


procedure  siftupfint :  position)  /*  Move  element  towards  the  Root  */ 
begin  /*  from  position  until  heap  is  satisfied  */ 

var 

int:  j,k; 

A_Line:  jobNumber;  /*  jobNumber  is  Priority  */ 

jobNumber  =  RQNode[RQSize].JobNumber;  /*  retrieve  the  job  number  */ 
RQNode[0]  =  RQNodefposition];  /*  save  the  present  node  */ 

k  =  position;  /*  save  the  present  position  */ 

j  =  position  div  2; 


while  RQNode[j].JobNumber  >  jobNumber  do 
begin 

RQNodePtrfk]  =  RQNodePtrfj];  /*  find  proper  location  */ 

k  =  j; 

j  =j  div  2; 
end; 

RQNodefk]  =  RQNode[0];  /*  location  found  move  element  there  */ 
end; 


Figure  3.10  Siflup  -  Move  an  Element  Towards  the  Root  [Ref.  5  :  pp.  243-245] 
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Figure  3.11(a)  Heap  Implemenation  of  a  Priority  Queue 


Figure  3.11(b)  Heap  After  Element  012  is  Added 
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4.  Dequeue  Routine 


To  remove  an  element  from  the  queue,  the  Dequeue  routine  is  called. 
Figure  3.12  shows  a  pseudocode  routine  for  Dequeue.  The  Dequeue  function 
is  illustrated  in  a  flow  diagram  in  Figure  3.13.  The  Dequeue  function  is  a 
relatively  simple  operation  with  the  complex  operations  taking  place  in  the 
Siftdown  routine. 

The  Dequeue  routine  shown  does  not  return  a  value,  however  it  could 
return  the  node  which  was  removed.  Figure  3.14  shows  the  heap  of  integers 
from  Figure  3.11(b)  after  calling  the  Dequeue  module.  The  element  004  was 
removed  and  the  heap  restructured. 

procedure  dequeue 
begin 

/*  Put  a  lower  priority  job  on  top  of  the  heap  */ 

RQNodePtrfl]  =  RQNodePtr[RQSize]; 

RQSize  =  RQSize  -1;  /*  decrease  RQ  Size  */ 

siftdown(l);  /*  restructure  heap  */ 

end; 

Figure  3.12  Dequeue  Top  Element  From  the  Queue  [Ref.  5  :  pp.  243-245] 

5.  Siftdown  Routine 

The  function  called  Siftdown  moves  an  element  from  the  root  towards 
a  leaf  node.  The  process  continues  until  the  heap  conditions  are  satisfied. 
This  process  again  requires  at  most  0(log2  n)  effort.  Figure  3.15  shows  the 
Siftdown  procedure. 

The  operating  system  designed  for  this  thesis  has  modified  the 
pseudocode  modules  presented  in  the  figures  by  using  pointers  to  data 
nodes  in  the  actual  heap  rather  than  the  nodes  themselves.  The  reason  for 
using  pointers  is  that  it  is  easier  to  shift  a  single  value  up  and  down  the  tree 
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Figure  3.13  The  Dequeue  Module 
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Figure  3.14  Heap  After  Element  004  is  Dequeued 
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procedure  siftdown(int :  position) 

begin 

var 

int:  i,j; 

RQNode  save; 
boolean  finished; 


/*  move  node  down  to  satisfy  */ 

/*  heap  relative  to  its  descendants  */ 


i  =  position; 

j  =  2*position; 

save  =  RQNodetposition]; 

finished  =  FALSE; 

while(j<=  RQSize)  and  not  finished  do  /*  while  there  are  children  */ 
begin  /*  and  position  is  not  found  */ 

/*  if  there  are  two  children  -  select  the  smaller  */ 
ifCj  <  RQSize)  and  (RQNode[j].JobNumber  >  RQNode[j+l].JobNumber) 
then  j  =  j  +  1; 

/*  if  the  position  is  found  then  finished  */ 
iffsave.JobNumber  <=  RQNode[j].JobNumber) 
then  finished  =  TRUE; 
else 

begin  /*  if  not  -  move  everything  up  and  try  again  */ 

RQNodefi]  =  RQNodefj]; 
i  =j; 
j  =  2*i; 

end; 

end; 

RQNodefi]  =  save; 

end; 


Figure  3.15  Siftdown  Routine  Moves  Elements  Towards  the  Leaf  Nodes 
[Ref.  5  :  pp.  243-245] 
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than  to  move  around  an  entire  data  structure  almost  twenty  times  the  size 
of  the  pointer.  However,  using  pointers  without  dynamic  memory 
allocation  meant  having  to  keep  track  of  the  free  space  in  the  block  of 
memory  assigned  to  the  nodes  holding  the  data.  Having  to  keep  track  of 
free  space  in  the  queue  was  additional  overhead  but  nowhere  near  the 
overhead  of  moving  entire  nodes. 

6.  Purge  Routine 

Another  requirement  of  the  operating  system  is  the  need  for  a  Purge 
routine.  Originally,  it  was  thought  that  a  job  could  wait  in  the  queue  until  it 
was  processed  and  at  the  time  of  its  processing  it  could  be  determined  if  the 
job  was  still  valid  or  not.  However,  every  twenty  milliseconds  new  jobs  will 
be  added  to  the  queue.  Without  a  tremendous  amount  of  memory,  all  the 
jobs  enqueued  cannot  be  allowed  to  stay  in  the  queue  indefinitely.  The 
Purge  routine  purges  or  removes  jobs  that  are  no  longer  valid.  Based  on 
whether  or  not  the  valid  bit  is  set,  the  job  is  technically  "dequeued"  from  the 
middle  of  the  queue.  The  job  is  dequeued  because  the  Purge  and  Dequeue 
functions  are  so  similar,  but  Dequeue  is  restricted  to  the  top  job  in  the 
queue.  Figure  3.16  shows  the  flow  diagram  for  the  Purge  module. 

The  Purge  routine  shown  in  Figure  3.17  is  essentially  the  same  as  the 
Dequeue  routine  with  the  job  being  removed  from  the  middle  of  the  queue. 
Figure  3.18  shows  the  same  integer  heap  as  in  Figure  3.14,  but  the  elements 
012  and  015  have  been  purged  and  the  heap  restructured.  Since  the 
Siftdown  routine  usually  moves  an  element  a  lesser  distance  from  its  old 
location  than  from  the  root  to  the  leaf  node,  the  effort  required  to  purge  a 
single  job  from  the  queue  is  less  than  or  equal  to  0(log2n). 
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Figure  3.16  Purge  Module 


53 


procedure  Purge 
begin 
var 

int  index, temp; 
temp  =  RQSize; 

for  index  =1  to  index  <=  temp  do 
begin 

if(  JobNumber.validbit)  /*  is  Valid  bit  set?  */ 

begin 

RQNodePtr[index]  =  RQNodePtr[RQSize]; 

/*  put  lowest  job  position  in  place  of  purged  job  */ 

RQSize  =  RQSize  - 1 ;  /*  decrease  RQ  Size  */ 

siftdown(index);  /*  restructure  heap  */ 

end 

end; 

end; 


Figure  3.17  Purge  Routine  to  Remove  Jobs. 


Figure  3.18  Heap  after  elements  012  and  015  have  been  Purged 

The  majority  of  the  operating  system’s  time  is  spent  managing  the 
Ready  Queue.  The  beginning  of  every  minor  cycle  is  used  to  schedule  tasks 
into  the  queue  and  to  purge  tasks  no  longer  considered  valid.  The 
scheduling  routine  calls  Enqueue  for  each  job  it  adds  to  the  queue.  The 


54 


Central  Task  Processor's  dispatch  module  calls  the  Dequeue  function  upon 
completion  of  a  routine  to  remove  it  from  the  queue. 

There  are  some  smaller  modules  also  associated  with  the  Ready- 
Queue  whose  code  is  contained  in  the  appendix.  The  modules  full  and 
empty  return  a  boolean  based  on  the  status  of  the  queue.  Create  initializes 
the  queue  by  setting  the  size  of  the  queue  equal  to  zero  and  setting  up  the 
next  free  node  pointers.  Create  will  be  discussed  in  greater  detail  in  the 
initialization  section. 

F.  THE  TASK  SCHEDULER 

The  Task  Scheduler  is  responsible  for  the  scheduling  of  jobs  at  the 
beginning  of  each  minor  cycle.  The  Task  Scheduler  uses  the  Enqueue 
routine  to  place  jobs  in  the  Ready  Queue  and  then  increments  the  frame 
counter  to  indicate  a  new  minor  cycle.  The  Task  Scheduler  is  called  from 
and  returns  to  the  Cycle  Interrupt  Handler.  Figure  3.19  shows  the  flow 
diagram  for  the  Task  Scheduler. 

The  Task  Scheduler  is  responsible  for  determining  which  jobs  are 
scheduled  for  a  particular  frame.  Jobs  are  classified  by  how  often  they  must 
be  scheduled.  The  job  numbers  are  located  in  arrays  with  an  index,  an 
offset  and  a  constant  for  the  array  used  in  determining  which  jobs  will  be 
scheduled  for  a  frame.  There  are  four  job  arrays  in  the  implementation  of 
the  operating  system.  The  four  arrays  are  lists  of  jobs  to  be  scheduled  every 
frame,  every  other  frame,  every  fourth  frame  or  every  eighth  frame.  The 
frame  counter  is  masked  to  determine  an  offset  from  the  base  pointer  for 
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Figure  3.19  The  Task  Scheduler 


56 


each  array.  The  masking  of  the  frame  counter  is  accomplished  by 
performing  a  "bitwise  and"  operation  with  the  frame  counter  and  a 
constant  for  the  array.  The  constant  used  to  mask  the  frame  counter  is  the 
frequency  of  how  often  the  jobs  are  to  be  scheduled  minus  one.  Along  with 
the  offset  for  each  array  is  the  constant  stride  factor  that  is  the  job 
scheduling  rate.  For  example,  jobs  to  be  scheduled  every  fourth  frame  have 
a  constant  stride  of  four.  The  constant  stride  for  an  array  is  added  to  the 
offset  computed  from  the  Frame  Counter  and  this  sum  is  used  as  the  index 
for  the  array  of  the  first  job  to  be  enqueued.  The  constant  stride  is  added  to 
the  index  in  a  loop  until  the  limits  of  the  array  or  the  maximum  length  of 
the  list  is  reached  and  the  next  array  is  processed.  This  is  illustrated  in 
Figure  3.20. 


Array  of  jobs  scheduled  every  other  frame 


Using  the  offset 
calculated  below, 
the  following  jobs 
are  scheduled 
in  frame  A5. 


Mask  for  Jobs  Scheduled  Every  other  Frame  =  1 
Frame  Counter  =  00A5  Constant  Stride  =  2 
Offset  for  this  Frame  is  0001 bitand  00A5  =  0001 

Figure  3.20  Sample  of  the  Job  Mask 
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The  "C"  programming  language  is  particularly  useful  for  executing 
routines  like  the  Task  Scheduler.  In  Figure  3.21,  a  pseudocode  routine  for 
scheduling  is  shown.  Comparing  the  routine  in  Figure  3.21  to  the  "C" 
implementation  located  in  Appendix  A  shows  how  much  more  elegantly 
the  scheduling  routines  can  be  coded  in  "C".  Most  languages  do  not  have 
the  "bitwise  and"  capability  and  many  cannot  easily  loop  through  an  array 
with  a  constant  stride. 

The  scheduling  of  a  set  amount  of  tasks  on  a  regular  interval  is  essential 
to  the  design  of  the  operating  system  presented  in  this  thesis.  The  types  of 
jobs  and  their  execution  length  will  determine  which  jobs  and  how  many 
jobs  can  be  scheduled  into  a  single  minor  cycle.  A  desired  result  is  an  equal 
distribution  of  processing  time  over  all  cycles.  It  will  be  up  to  the 
programmer  who  codes  the  job  to  determine  whether  or  not  a  job  can  be 
distributed  over  many  minor  cycles  and  thus  form  a  major  cycle  for  the  job. 

The  length  of  the  jobs  to  be  scheduled  and  their  execution  frequency  will 
also  have  a  direct  impact  on  the  length  of  the  minor  cycle.  The  length  was 
originally  set  at  twenty  miliseconds  but  this  may  be  varied.  There  are  other 
factors  that  may  affect  how  long  the  minor  cycle  can  be,  however,  these 
factors  are  mainly  dependent  on  the  application  of  the  system. 

G.  INITIALIZATION 

The  kernel  of  the  operating  system  is  responsible  for  the  system 
initialization  on  power  up.  The  peripheral  chips  which  support  the 
microprocessor  must  all  be  initialized.  There  are  several  areas  of  memory, 
specific  to  the  microprocessor,  which  must  be  set  up  prior  to  execution  of 
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procedure  ScheduleO 
begin 


JobMask2  =  FrameCounter  bitand 
JobMask4  =  FrameCounter  bitand 
JobMask8  =  FrameCounter  bitand 


1;  /*  Calculate  job  masks  for  */ 
3;  /*  those  tasks  which  are  not  */ 
7 ;  /*  scheduled  every  frame  */ 


index  =  0; 

while  index  <  MAXEVERYl  do 

begin 

enqueue(EverylTime[index]); 
index  =  index  +1; 

end; 

index  =  JobMask2; 

while  index  <  MAXEVERY2  do 

begin 

enqueue(Every2Time[index]); 
index  =  index  +2; 

end; 

index  =  JobMask4; 

while  index  <  MAXEVERY4  do 

begin 

enqueue(Every4Time[index]); 
index  =  index  +4; 

end; 


/*  No  offset  required  for  these  jobs  */ 
/*  enqueue  those  that  are  scheduled  */ 
/*  every  frame  (minor  cycle).  */ 


/*  start  at  offset  for  this  frame  and  */ 
/*  enqueue  those  that  are  scheduled  */ 
/*  every  other  frame  (minor  cycle).  */ 


/*  start  at  offset  for  this  frame  and  */ 
/*  enqueue  those  that  are  scheduled  */ 
/*  every  fourth  frame  (minor  cycle).  */ 


index  =  JobMask8; 

while  index  <  MAXEVERY8  do 

begin 

enqueue(Every8Time[index]); 
index  =  index  +8; 

end; 


/*  start  at  offset  for  this  frame  and  */ 
/*  enqueue  those  that  are  scheduled  */ 
/*  every  eighth  frame  (minor  cycle).  */ 


FrameCounter  =  FrameCounter  +  1;  /*  increment  frame  counter  */ 

end; 


Figure  3.21  Schedule  Routine 
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the  operating  system's  normal  mode.  The  interrupt  vectors  and  trap  tables, 
common  to  most  microprocessors,  must  be  filled  with  the  proper  memory 
locations  so  that  once  the  operating  system  has  completed  the  set  up 
routine,  all  interrupts  may  be  serviced. 

Figure  3.22  shows  a  limited  overview  of  the  major  tasks  which  must  be 
done  upon  start  up.  Most  of  these  initialization  routines  are  written  in 
assembly  language  to  facilitate  the  access  to  the  hardware  and  to  speed  up 
the  process.  The  operating  system  described  in  this  thesis  was  developed  on 
a  microprocessor  system  that  the  had  already  completed  these  vector 
initializations  using  its  own  operating  system.  In  order  to  test  the 
operation  of  the  operating  system  developed  in  this  thesis,  some  of  these 
vectors  had  to  be  replaced  with  vectors  to  the  routines  in  the  thesis 
operating  system. 

The  Ready  Queue  must  be  set  up  during  the  initialization  phase.  Aside 
from  allocating  the  space  for  the  queue,  the  integer  pointers  in  the  nodes 
have  to  be  initialized.  The  nodes  are  an  array  of  data  structures  and  the 
pointer  to  the  next  free  node  is  the  array  subscript  of  the  next  free  node.  The 
next  free  node  variable  in  each  node  data  structure  is  initially  filled  with  the 
next  consecutive  node.  The  free  space  is  essentially  a  linked  list  with  array 
subscripts  used  for  pointers  instead  of  addresses.  The  storage  for  the  array 
of  nodes  and  node  pointers  is  allocated  when  the  arrays  are  declared  as 
global  variables  in  the  "C"  header  file.  The  header  file,  located  in 
Appendix  A,  contains  the  global  variable  storage  allocations  for  the  entire 
operating  system. 
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Figure  3.22  Initialization  of  the  System 
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The  array  of  pointers  and  the  array  of  nodes  must  be  tied  together 
during  initialization  by  setting  the  first  pointer  to  be  equal  to  the  address  of 
the  first  node.  The  process  which  accomplishes  the  initialization  of  the 
Ready  Queue  is  the  routine  Create  shown  in  Figure  3.23  below. 

procedure  createO 
begin 

RQSize  =  0;  /*  initialize  queue  to  empty  state  */ 

for  i=  0  to  i  <  RQMAXSIZE  do  /*  initialize  free  node  pointers  */ 
RQNodes[i].NextFreeNode  =  i+1;  /*  using  array  indices  */ 

RQNodePtrfO]  =  &RQNodes[0];  /*  Point  array  of  pointers  to  the  */ 
firstFree  =  1;  /*  contiguous  block  of  memory  */ 

lastFree  =  RQMAXSIZE  - 1;  /*  set  globals  for  first  &  last  free  */ 

end; 

Figure  3.23  Create  the  Ready  Queue 

The  next  phase  of  initialization  is  to  load  a  low  level  job,  a  small  monitor, 
into  the  queue.  The  monitor  will  never  be  removed  from  the  queue  since  it 
never  completes  its  execution  and  never  returns  back  to  a  calling  program. 
The  monitor  is  assigned  the  lowest  priority  of  any  job  that  could  be 
scheduled. 

After  loading  the  monitor,  the  timer  is  initialized  and  started  and  the 
control  of  the  program  is  given  to  the  Central  Task  Processor  for  execution 
of  the  first  job  in  the  Ready  Queue.  The  timer  used  for  this  thesis  was  a 
SY6522  Versatile  Interface  Adapter.  The  initialization  consisted  of 
programming  one  of  the  two  sixteen  bit  interval  timers  located  on  the 
SY6522  to  interrupt  the  microprocessor  at  the  beginning  of  every  minor 
cycle. 
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In  the  development  of  a  single  microprocessor  system,  there  are  several 
initialization  steps  which  can  be  overlooked.  The  most  significant 
initializations  to  be  done  in  a  multi-processor  system  is  the  establishment  of 
inter-processor  communications  and  synchronization  of  the  processors. 
These  two  vital  tasks,  communications  and  synchronization,  are  the 
responsibility  of  the  operating  system  kernel. 
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IV.  PERFORMANCE  MEASUREMENTS 


A.  BACKGROUND 

The  operating  system  was  implemented  on  a  MC68000  based  personal 
microcomputer  to  allow  convenient  testing  of  the  modules.  The  Ready 
Queue  was  written  and  tested  first  because  it  was  believed  that 
manipulating  and  maintaining  the  Ready  Queue  would  be  the  most  time 
critical  area  for  the  operating  system.  This  belief  was  based  on  the  fact  that 
at  the  beginning  of  every  minor  cycle  the  scheduler  would  have  to  enqueue  a 
preset  number  of  jobs  and  at  the  end  of  the  minor  cycle  some  jobs  might 
have  to  be  purged. 

The  development  hardware  used  to  do  the  implementation  and  testing 
was  not  optimal.  Not  only  is  a  personal  microcomputer  not  designed  for 
system  development  (lack  of  a  dual  bus  system,  separate  exception  tables, 
hardware  breakpoints,  trace  capture,  etc.)  but  a  personal  microcomputer 
usually  has  several  features  which  slow  the  speed  of  the  overall  system.  A 
personal  microcomputer  also  uses  shortcuts  in  the  hardware  design  to  save 
on  the  final  cost  of  the  product.  There  were  several  system  tasks  important 
to  the  host  microcomputer  being  carried  out  at  the  same  time  as  the  testing 
of  the  operating  system  routines.  The  details  of  the  hardware  layout  are  in 
Appendix  C. 

As  an  example  to  illustrate  some  of  the  hindrances  in  the  execution  of 
the  test  routines,  the  microcomputer  required  a  screen  refresh  every  16.67 
milliseconds.  A  screen  refresh  is  a  level  one  interrupt  and  it  was  not 
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feasible  to  replace  all  level  one  interrupt  routines  with  the  routine  for  the 
timer  interrupt  which  shared  a  level  one  status.  The  computer  used  a 
secondary  vector  table  to  route  the  level  one  interrupt  routines  to  their 
proper  handlers.  The  Cycle  Interrupt  routine  was  vectored  from  the 
secondary  vector  table. 

Even  though  the  test  environment  was  not  optimal,  measurements  were 
taken  for  execution  times  of  the  different  ready  queue  routines  for 
comparative  purposes.  Measurements  were  not  taken  of  the  routines 
written  in  assembly  language.  The  assembly  language  routines  were  so 
short  that  a  more  accurate  indication  of  the  assembly  language  routine's 
execution  times  could  be  calculated  adding  up  the  individual  instruction 
times.  The  individual  instructions  execution  times  are  available  in  the 
Appendix  of  Reference  [7],  The  minor  cycle  used  to  test  the  operating 
system  was  sixty  milliseconds.  The  extra  time  was  required  due  to  the 
operating  environment. 

The  efficiency  of  the  compiler  is  another  factor  to  consider  when 
evaluating  the  execution  times  of  various  routines.  The  time  for  execution 
of  a  routine  may  vary  for  different  compilers.  A  routine  may  execute  at  a 
slower  speed  if  the  compiler  does  not  optimize  the  final  object  code  by 
making  several  compilation  passes  and  stripping  dead  code.  The  compiler 
used  in  the  generation  of  the  operating  system  in  this  thesis  was  the  Mac 
C™  compiler  by  Consulair  Corporation.  This  compiler  should  not  be 
considered  optimal.  It  makes  only  one  pass  of  the  "C"  code  for  compilation, 
one  pass  for  preprocessor  commands  and  one  pass  for  assembling  in-line 
assembly  language  code. 
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There  were  benefits  in  developing  the  operating  system  on  a 
microcomputer.  One  benefit  is  that  the  software  could  be  tested  on  a  proven 
hardware  system  eliminating  the  conflicts  of  bugs  from  both  hardware  and 
software.  Another  benefit  is  that  a  run  time  library  need  not  be  built  in 
order  to  use  the  higher  level  routines  in  "C",  such  as  input  from  the 
keyboard  and  output  to  the  screen.  The  operating  system  was  developed  to 
be  used  on  another  MC68000  system  but  an  emphasis  was  placed  on 
portability  . 

Many  of  the  routine  tasks  that  would  normally  have  to  be  coded,  as  in  the 
initialization  routines,  had  already  been  accomplished  by  the  personal 
microcomputer's  own  operating  system.  The  microcomputer  environment, 
while  not  optimal  for  evaluation  of  the  final  product,  can  be  used  in  the 
development  of  systems  software. 

B.  COMPARISONS 
1.  Scheduling 

The  Scheduler  is  called  at  the  beginning  of  every  minor  cycle.  The 
Scheduler  then  calls  the  routine  Enqueue  several  times  depending  on  how 
many  jobs  are  being  scheduled  in  the  frame.  The  execution  time  of  the 
scheduler  is  directly  related  to  the  efficiency  of  the  Enqueue  routine.  Other 
than  enqueueing  jobs,  the  Scheduler's  only  other  tasks  are  to  calculate  the 
job  offsets  for  each  job  list  and  increment  the  Frame  Counter. 

Since  the  order  of  magnitude  for  a  queue  insertion  is  O(log2  n),  the 
order  of  magnitude  for  inserting  n  items  in  the  queue  should  be  0(n  log2  n). 
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The  graph  in  Figure  4.1  shows  the  execution  times  for  loading  the  ready 
queue  using  the  Schedule  routine  three  different  times.  The  schedule 
routine  inserted  eight  jobs  per  minor  cycle  into  the  ready  queue.  The  queue 
was  essentially  full  after  six  minor  cycles  since  no  execution  of  tasks  or 
purges  were  taking  place.  The  time  to  schedule  eight  jobs  does  not  appear  to 
increase  substantially  as  the  queue  gets  full,  but  it  does  increase. 
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Figure  4.1  Schedule  Routine  Performance 


The  numbers  used  to  generate  Figure  4.1  are  found  in  Appendix  D.  It 
would  appear  that  it  takes  on  the  average  approximately  2.5  milliseconds  to 
schedule  eight  jobs  into  the  ready  queue.  Not  allowing  for  the  mask 
calculations  or  incrementing  the  frame  counter,  it  takes  about  0.3 
milliseconds  to  schedule  one  job  into  the  ready  queue.  This  is  not  an 
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acceptable  figure  for  a  twenty  millisecond  minor  cycle.  However,  the 
measurements  taken  should  be  considered  relative  for  comparison  to  other 
measurements  taken  on  the  same  system,  due  to  the  environment,  and  do 
not  reflect  the  true  performance  of  the  operating  system  in  a  dedicated 
system. 

2.  Purging 

Purging  of  the  Ready  Queue  must  take  place  prior  to  the  scheduling  of 
new  tasks  in  a  new  minor  cycle  to  make  room  for  the  new  jobs.  The  purge 
operation  will  usually  not  remove  the  same  number  of  jobs  each  minor 
cycle  since  not  all  jobs  in  the  Ready  Queue  are  purgeable.  There  may  be  a 
minor  cycle  in  which  two  or  more  items  are  purged.  The  most  likely 
occurrence  is  the  case  of  one  or  no  jobs  purged  per  minor  cycle. 

A  major  factor  affecting  the  execution  speed  of  the  purge  routine  is 
the  location  of  the  job  in  the  heap  which  is  the  Ready  Queue.  A  job  which  is 
higher  in  the  Queue  with  a  higher  priority  and  is  closer  to  the  root  will  take 
longer  to  purge  than  a  job  located  in  a  leaf  node.  The  location  dependence  of 
purge  time  differences  is  due  to  the  siftdown  routine  called  to  restructure 
the  heap.  The  job  from  the  lowest  location  in  the  heap  is  placed  in  the 
location  of  the  old  purged  job,  therefore,  the  closer  the  purged  job  to  the  leaf 
node,  the  less  "sifting  down"  that  has  to  be  done  to  put  the  heap  back  in 
order. 

Since  there  are  so  many  factors  affecting  the  execution  time  of  the 
purge  routine,  an  in-depth  analysis  was  not  done.  It  was  believed  that  due 
to  the  nature  of  the  environment,  the  measurements  would  not  be  accurate 
enough  to  be  of  any  significance.  The  factors  involved  in  a  call  to  the  Purge 
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routine  include  the  size  of  the  Ready  Queue  when  Purge  is  called  and  the 
number  of  purgeable  jobs  in  the  queue  and  their  locations.  It  should  be 
noted  that  the  bound  on  the  performance  of  a  single  Purge  is  of  0(log2  n), 
the  same  as  a  dequeue  or  a  purge  of  the  top  element  in  the  queue. 

3.  Enaueueing 

The  performance  of  a  single  insertion  into  the  queue  is  of  0(log2  n). 

The  main  factors  affecting  the  execution  time  of  the  enqueue  routine  are  the 
size  of  the  queue  and  the  priority  of  the  job  being  inserted.  Only  a  single 
entry  at  a  time  is  made  into  the  queue.  The  Enqueue  routine  calls  the  Siftup 
routine  to  restructure  the  queue  after  a  new  element  has  been  added.  It 
should  be  noted  that  the  order  of  a  single  insertion  is  an  upper  bound  to  the 
execution  time  of  a  single  insertion.  If  the  new  element  happens  to  be  the 
lowest  priority  job  in  the  queue  then  no  restructuring  will  be  necessary  and 
the  time  to  execute  the  Enqueue  routine  will  be  less  than  0(log2  n). 

Since  the  execution  time  of  a  single  queue  insertion  is  dependent  on 
the  size  of  the  queue  as  well  as  the  priority  of  the  job  being  inserted, 
consideration  of  the  job's  priority  must  be  taken  into  account  when  deciding 
which  jobs  will  be  scheduled  into  the  different  minor  cycles.  If  many  high 
priority  jobs  are  enqueued  at  one  time,  it  could  conceivably  slow  the 
Scheduler  down  so  that  there  would  be  as  much  time  left  in  the  minor  cycle 
for  job  execution. 

The  performance  of  the  enqueue  routine  is  encompassed  by  the 
performance  measurements  of  the  the  scheduler.  Measurements  taken  of 
individual  enqueueing  operations  would  be  meaningless  unless  the  heap 
was  shown  before  and  after  each  insertion  and  the  job  placement  in  the 
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queue  was  monitored  carefully.  Even  keeping  track  of  the  queue  structure, 
there  are  the  other  variables  of  the  queue  size  and  the  priority  of  the  job  to 
be  inserted. 

4.  Dequeueing 

The  Dequeue  routine  is  not  called  until  the  job  that  is  being  removed 
from  the  queue  has  completed  execution.  Dequeue  calls  the  Siftdown 
routine  to  restructure  the  heap  and  since  the  lowest  priority  job  is  placed  in 
the  highest  priority  position,  the  time  to  perform  a  removal  from  the  queue 
is  always  0(log2  n).  Therefore,  the  main  factor  in  affecting  the  performance 
of  the  Dequeue  routine  is  the  size  of  the  queue.  The  illustration  of  the 
Dequeue  routine's  dependency  on  the  size  of  the  queue  is  illustrated  in 
Figure  4.2.  A  logarithmic  interpolation  curve  is  used  in  Figure  4.2  to 
emphasize  the  log  relationship  between  the  performance  of  the  Dequeue 
routine  and  the  size  of  the  queue. 

C.  CONCLUSIONS 

The  operating  system  was  not  tested  in  an  environment  that  allowed  for 
an  accurate  performance  evaluation.  The  routines  that  were  tested 
appeared  to  do  relatively  well.  The  times  are  inflated  due  to  the  conditions, 
however,  the  times  appear  to  reflect  the  proper  operation  of  the  queue 
management  routines. 
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time  in  ms 


Queue  Performance  for  a  Dequeue 


n  -  Number  of  Elements  in  the  Queue 
Figure  4.2  Performance  of  the  Dequeue  Routine 
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V.  CONCLUSIONS 


A.  SUMMARY  OF  RESULTS 

The  principal  goal  of  this  thesis  was  the  development  of  a  kernel  for  a 
real  time  fault  tolerant  operating  system.  The  modules  which  make  up  the 
operating  system  kernel  were  designed  and  tested  individually  before  being 
combined  to  form  the  bulk  of  the  operating  system  kernel.  The  objectives  of 
the  thesis  were  met  to  the  extent  that  an  operating  system  kernel  was 
designed  for  a  real  time  fault  tolerant  environment  and  implemented  on  a 
MC68000  based  microcomputer. 

The  real  time  requirement  was  described  by  the  ability  of  the  operating 
system  to  respond  to  events  as  they  occurred.  The  interrupt  handler  of  the 
operating  system  meets  this  requirement.  If  a  real  time  request  interrupts 
the  processor  with  a  high  enough  priority  to  be  placed  on  the  top  of  the 
Ready  Queue,  it  is  serviced  immediately.  There  are  other  external 
influences  which  will  need  to  be  serviced  in  real  time  but  that  are  not 
handled  by  the  interrupt  handler. 

A  major  requirement  which  must  be  addressed  before  this  operating 
system  can  be  implemented  in  a  multiprocessor  environment  is  the  ability 
to  communicate  with  the  other  processors.  This  will  be  an  operating  system 
kernel  function  with  real  time  requirements. 

The  use  of  the  A-Line  trap  to  monitor  the  execution  of  all  jobs  was 
originally  intended  to  enhance  the  fault  tolerance  of  the  operating  system 
without  impeding  operating  system  efficiency.  The  assignment  of  an 
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A-Line  and  priority  to  each  routine  ensures  that  the  operating  system  is 
aware  of  the  status  of  all  active  jobs.  However,  the  combination  of  the 
Central  Task  Processor  and  the  A-Line  trap  results  in  redundant 
management.  The  A-Line  trap  actually  slowed  the  performance  of  the 
operating  system  by  adding  extra  instructions  to  handle  the  A-Line 
exception  in  order  to  execute  a  job.  A  table  of  contents  could  be  used  with  the 
same  effect  as  the  A-Line  trap  and  with  better  efficiency.  The  jobs'  starting 
addresses  could  be  located  in  a  table  of  contents  and  still  be  prioritized  by  job 
number  in  the  table.  Using  a  table  of  contents  eliminates  the  need  to  go 
through  the  A-Line  trap  handler. 

The  use  of  "C"  is  required  to  maintain  portability  between  systems  but 
the  object  code  produced  by  the  "C"  compiler  may  not  be  optimal.  Most  "C" 
compilers  contain  a  feature  that  allows  the  generation  of  an  intermediate 
assembly  language  file  during  compilation.  The  intermediate  assembly 
language  code  could  be  optimized  for  time  consuming  operations  performed 
by  the  operating  system.  The  reason  for  optimization  is  that  many 
compilers  inherently  include  dead  code  and  duplicate  instructions  in  the 
object  code  created  as  a  result  of  the  compilation.  The  removal  of  the  dead 
code  from  the  intermediate  assembly  language  file  should  help  the 
operating  system  achieve  better  performance. 

A  hardware  system  for  the  design  and  implementation  of  the  operating 
system  is  required.  Without  the  intended  microcomputer  system  available 
for  the  operating  system,  many  routines  dealing  with  hardware  specific 
functions  of  the  operating  system  could  not  be  written  and  tested. 
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B.  RECOMMENDATIONS  FOR  FURTHER  RESEARCH 

The  operating  system  kernel  developed  in  this  thesis  will  need  to  be 
expanded  upon  as  more  sophisticated  functions  are  required.  The  ability  to 
send  and  receive  messages  between  processors  in  a  multiprocessor  system 
will  require  the  support  of  input/output  functions.  The  addition  of  a  full 
function  input/output  capability  and  additional  processors  in  the  system 
will  produce  a  requirement  for  semaphores  to  monitor  the  use  and 
availability  of  the  input/output  resources.  The  addition  of  semaphores 
means  the  requirement  for  an  additional  queue  for  jobs  which  are  waiting 
for  blocked  resources.  There  will  then  be  a  requirement  for  a  Ready  Queue 
and  a  Waiting  Queue. 

Further  research  into  the  operating  system  will  require  a  proper 
development  station.  The  personal  computer  used  to  develop  the  operating 
system  kernel  was  not  a  true  development  environment.  A  hardware 
design  that  is  intended  for  a  real  time  fault  tolerant  environment  should  be 
used  to  test  future  versions  of  the  operating  system.  The  use  of  the  proper 
hardware  will  help  to  increase  the  accuracy  of  the  results  for  the  test  and 
evaluation  of  the  operating  system  routines. 
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APPENDIX  A 


C  AND  ASSEMBLY  LANGUAGE  SOURCE  CODE  LISTINGS 

This  Appendix  contains  the  source  code  modules  required  for  the 
operating  system.  The  listings  start  with  the  header  file  which  was 
included  in  each  source  code  module.  The  "Main"  function,  required  in  a 
C  language  program,  is  in  the  file  OSTest.c  and  has  been  made  as  generic 
as  possible  considering  the  development  environment.  All  the  other 
listings  follow.  A  block  diagram  illustrating  the  exection  flow  between 
modules  is  loacted  in  Figure  A.l 

The  C  programming  language  was  commented  as  much  as  possible 
to  enhance  readability.  The  standard  C  as  professed  by  Kernighan  and 
Ritchie  in  Reference  [6]  was  used  to  insure  portability.  The  modules  are 
presented  in  the  approximate  order  in  which  they  are  used.  Each  section 
denoted  by  a  heading  of  a  module  name  is  a  different  file,  compiled 
separately  and  later  linked  together. 

The  file  OSTest.c  was  modified  to  test  each  module  as  it  was  written. 
Also  some  files  were  modified  to  use  the  SY6522  timer  to  time  the 
performance  of  the  routine  and  gather  the  data  in  Appendix  D. 
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Figure  A.1  Operating  System  Module  Flow  Diagram 


*****************  A  LINETEST.H 


/*  A-linetest.h,  header  file  for  Operating  System  Global  Variables  */ 


#include  "C_Heads.h"  /*  include  Macintosh  stdio.h  pre-compiled  */ 

#define  TRUE  1 
#define  FALSE  0 


#define  RQMAXSIZE  50 


/*  max  size  of  ready  queue  */ 


/*  These  constants  are  the  max 
#define  MAXEVERY1  5 
#define  MAXEVERY2  4 
#define  MAXEVERY4  8 
#define  MAXEVERY8  16 


number  of  jobs  that  can  be  scheduled  -  */ 
/*  -  every  frame  */ 

/*  -  every  other  frame  */ 

/*  -  every  fourth  frame  */ 

/*  -  every  eighth  frame  */ 


#define  MAXJOBNUMBER  1023  /*  max  total  number  of  jobs  =  03FF  */ 


struct  _RQInfo  /*  the  Ready  Queue  Node  */ 

{ 


short 

JobNum; 

/*  A-line  trap  number 

*/ 

long 

FrameStart; 

/*  Frame  Scheduled  in 

*/ 

short 

SerialNum; 

/*  Index  for  TOC  and  Q 

*/ 

int 

NextFreeNode; 

/*  index  number  of  next 

*/ 

long 

DataO; 

/*  all  Data  and  Address 

*/ 

long 

Datal; 

/*  Registers  stored  here 

*/ 

long 

Data2; 

long 

Data3; 

long 

Data4; 

long 

Data5; 

long 

Data6; 

long 

Data7; 

long 

AddrO; 

long 

Addrl ; 

long 

Addr2; 

long 

Addr3; 

long 

Addr4; 

long 

Addr5; 

long 

Addr6; 

long 

}; 

Addr7 ;  /*  stack  points  at  SR  and  PC  */ 

#define  RQNode 

struct  _RQInfo 

/*  define  Node  */ 

typedef  RQNode 

*RQPtr; 

/*  define  pointer  to  a  node  * 
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#ifdef  MAIN 


/*  if  compiling  the  main()  program  */ 


int 

RQNode 

RQPtr 

unsigned  char 
int 
int 

unsigned  long 

short 

short 

short 

short 

unsigned  long 

extern 

long 

short 

long 


i,j,k,l,m;  /*  general  indices  list  */ 

RQNodes[RQMAXSIZE];  /*  make  space  for  Nodes  */ 
RQNodePtr[RQMAXSIZE];  /*  make  space  for  pointers  */ 
SerialList[MAXJOBNUMBER];  /*  serial  number  array  */ 
RQSize  /*  The  size  of  the  ready  queue  */ 

firstFree,lastFree;  /*  for  keeping  track  of  free  space  */ 
JobMask2,JobMask4,JobMask8;  /*  masks  for  scheduler  */ 
E v ery  1  Time [M AXE VERY1];  /*  These  are  the  arrays  of  */ 


Every2Time[M  AXE  VERY2] ; 
Every4Time[M  AXEVERY4] ; 
E  very8Time[MAXE  VERY8] ; 
FrameCounter; 

RQPtr  serveO; 
GlobalRegs[16],MacTraps; 
TopJob.PresentJob; 
Regs,01dJob; 


/*  job  numbers,  classified  */ 
/*  into  lists  of  how  often  */ 
/*  they  are  scheduled.  */ 
/*  global  32  bit  value  */ 

/*  if  serve  returns  a  value  */ 
/*  These  variables  were  */ 
/*  for  use  in  ASM  code  */ 


#else  /*  all  global  variable  storage  space  is  defined  in  the  main  file  */ 


extern 

int 

extern 

RQNode 

extern 

RQPtr 

extern 

unsigned  char 

extern 

int 

extern 

int 

extern 

unsigned  long 

extern 

short 

extern 

short 

extern 

unsigned  long 

extern 

long 

extern 

short 

extern 

long 

i,j,k,l,m; 

RQNodesG; 

RQNodePtr[]; 

SerialListG; 

RQSize, 

firstFree,lastFree; 
JobMask2,JobMask4,JobMask8; 
Everyl  Time[]  ,E  very2Time[] ; 
Every  4Time[]  ,E  very8Time[] ; 
FrameCounter; 

GlobalRegsG  ,MacTraps; 

TopJob.PresentJob; 

Regs.OldJob; 


#endif 


^<^+^^4:^**+*******  OSTEST  0  ***************** 

/*  This  program  contains  the  main()  routine  which  is  responsible  for  the  */ 
/*  initialization  of  the  queue  and  all  other  global  variables.  It  is  */ 

/*  responsible  for  the  set-up  of  the  operating  system  and  the  loading  of*/ 

/*  the  monitor  prior  to  the  calling  of  the  Central  Task  Processor.  While  */ 

/*  it  contains  a  never  ending  loop,  this  loop  will  never  be  executed  */ 

/*  more  than  once.  Once  control  is  passed  to  the  Central  Task  Processor,  */ 
/*  it  never  returns  here.  */ 
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#define  MAIN 

#include  "A-linetest.h"  /*  include  header  file  */ 


InitSystemO 

{ 

FlushEvents(everyEvent);  /*  cleans  out  Event  Queue  on  Macintosh  */ 


createO; 

FrameCounter  =  0; 

SetUpTimerO; 

InitALineO; 

1 


/*  Creates  the  ready  queue  */ 

/*  Insure  frame  counter  starts  at  zero  */ 

/*  Set  up  SY6522  VIA  for  cycle  interrupts*/ 
/*  Load  our  trp  handler  in  low  memory  */ 


main() 

{ 

InitSystemO; 
enqueue(0xF003); 

#asm 

XREF  doSchedule 

LEA  doSchedule, AO 
MOVE.L  AO, $192 
#endasm 

while  (TRUE)  {  /*  endless  loop  */ 

CTP();  /*  Let  Central  Task  Processor  take  over  */ 

} 

}  /*end  of  main()  */ 

SetUpTimerO 

{ 

#asm 

VIA  EQU  $1D4  ;  VIA  base  address  [pointer] 

vIER  EQU  $1C00  ;  INT.  ENABLE  REG. 

MOVEA.L  VIA, AO 

BCLR  #6,vIER(A0)  ;  disable  timerl  interrupt  until  ready 

#endasm 

1 


/*  do  initialization  */ 

/*  enqueue  the  monitor  */ 

/*  in-line  assembly  allowed  */ 

;  Loads  our  routine  into  dispatch  table 
;  Level  1  Interrupt  -  secondary  table 


CTP  ASIVl  ***************** 

/*  The  Central  Task  Processor  was  written  entirely  in  assembly  */ 
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/*  for  ease  of  accessing  the  A-Line  trap  and  for  speed. 


*/ 


INCLUDE  M68KLIB.D 


required  assembly  library 


XREF  RQNodePtr 


only  external  variable 


CTP: 

MOVE.L  RQNodePtr+4(A5),A0 
MOVE.W  (AO), DO 
AND  #$800, DO 

BEQ  newjob 


;  retrieve  node  pointer 
;  retrieve  job  number 
;  test  to  see  if  new  job  or  not 
;  if  new  use  A-line 


MOVEM.L  12(A0),D0-D7/A0-A7  ;  restore  regs 

RTE  ;  continue  interrupted  job 


newjob: 

LEA  Atrap,Al 

MOVE.W  (A0),(A1) 
Atrap: 

DC.W  $4E71 

END 


;  Load  address  space 
;  move  A-Line  there 

;  Reserved  word  for  A-Line 


READYQ  C  ***************** 


/*  ReadyQ.c  -  This  module  includes  all  the  functions  required  */ 

/*  for  set  up  and  maintenance  of  the  ready  queue.  */ 

#include  "A-linetest.h"  /*  includes  all  global  variables  */ 

/* . Enqueue . */ 

enqueue(jobNum)  /*  add  a  job  to  the  queue  */ 
short  jobNum; 

{ 

unsigned  short  index,  shifted; 

ifiRQSize  ==  RQMAXSIZE)  /*  normally  would  want  to  */ 

return;  /*  set  an  alarm  here  */ 

RQSize  +=  1;  /*  increase  RQ  Size  */ 

RQNodePtrfRQSize]  =  &RQNodes[firstFree];  /*  get  free  space  for  job  */ 
firstFree  =  RQNodes[firstFree].NextFreeNode;  /*  change  first  free  space  */ 
RQNodePtr[RQSize]->JobNum  =  jobNum;  /*  Load  Job  Number  and  */ 
RQNodePtr[RQSize]->FrameStart  =  FrameCounter;  /*  Frame  Number  */ 

index  =  (jobNum  &  0x03FF);  /*  Index  for  serial  number  list  */ 
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shifted  =  index  «  4;  /*  put  jobnum  in  High  byte  1/2  */ 

/*  Serial  number  =  I  Jobnum  I  serial  numl  */ 
RQNodePtr[RQSize]->SerialNum  =  SerialList[index]  +  shifted; 
SerialList[index]  +=1;  /*  inc  serial  num  for  that  job*/ 

siftup(RQSize);  /*  Move  it  towards  Root  */ 

} 

/* - Serve - */ 

RQPtr  serveQ  /*  Remove  the  top  job  from  the  queue.  */ 

{ 

RQPtr  JobPtr; 
short  index,  shifted; 
int  next; 

JobPtr  =  RQNodePtr[l];  /*  Retrieve  the  highest  Priority  */ 

next  =  JobPtr  -  &RQNodes[0];  /*  make  the  now  vacant  space...  */ 

RQNodes[lastFree].NextFreeNode  =  next;  /*  the  last  free  space  */ 
lastFree  —  noxt* 

RQNodePtr[l]  =  RQNodePtr[RQSize];  /*  Put  low  job  at  the  top  */ 
RQSize  -=  1 ;  /*  decrease  RQ  Size  */ 

siftdown(l);  /*  restructure  heap  */ 

return(JobPtr); 

} 

/* . Create - */ 

createO  /*  Sets  up  the  global  variables  for  the  ready  queue.  */ 

{ 

RQSize  =  0;  /*  Initialize  queue  to  empty  state  */ 

for(i=  0;  i  <  RQMAXSIZE  -1;  i++)  /*  Initialize  free  node  pointers  */ 

RQNodes[i].NextFreeNode  =  i+1; 

RQNodePtr[0]  =  &RQNodes[0];  /*  Point  array  of  pointers  to  the  */ 

firstFree  =  1;  /*  contigous  block  of  memory  */ 

lastFree  =  RQMAXSIZE  - 1;  /*  set  globals  for  first  &  last  free  */ 

} 

/* - Siftup - */ 

siftup(pos)  /*  Move  towards  Root  */ 

int  pos; 

{ 

int  j,k; 
short  serialnum; 
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serialnum  =  RQNodePtr[pos]->SerialNum;  /*  retrieve  the  serial  number*/ 
RQNodePtr[0]  =  RQNodePtr[pos];  /*  save  the  present  node  pointer  */ 

k  =  pos;  /*  save  the  present  position  */ 

j  =  (int)(pos/2);  /*  get  the  first  parent’s  postion  */ 


while(RQNodePtr[j]->SerialNum  > 

{ 

RQNodePtr[k]  =  RQNodePtr[j]; 
k=j; 

j  =  (int)(j/2); 

) 

RQNodePtr[k]  =  RQNodePtr[0]; 

} 

/* . Siftdown . 


serialnum) 

/*  move  up  one  place  */ 
/*  and  compare  the  child  */ 
/*  with  its'  parent  */ 


/*  location  found  move  element  there  */ 


*/ 


siftdown(pos)  /*  move  node  down  to  satisfy  the  */ 

int  pos;  /*  heap  relative  to  its  descendants  */ 

{ 

int  i,j; 

RQPtr  save; 
char  finished; 

i  =  pos;  /*  will  want  to  start  with  parent  */ 

j  =  2*pos;  /*  and  start  with  one  of  its  children  */ 

save  =  RQNodePtr[pos];  /*  save  new  node  until  finished  */ 

finished  =  FALSE;  /*  boolean  to  know  when  we're  done  */ 

while((j<=  RQSize)  &&  ([finished))  /*  while  there  are  children  */ 

( 


/*  if  there  are  two  children  -  select  the  smaller  */ 
if((j<RQSize)  &&(RQNodePtr[j]->SerialNum  >  RQNodePtr(j+l]>SerialNum)) 

j+=i; 

/*  if  the  position  is  found  then  it's  finished  */ 
if(save->SerialNum  <=  RQNodePtr[j]->SerialNum  ) 
finished  =  TRUE; 
else 

/*  if  not  -  move  next  node  up  and  try  again  */ 

{ 

RQNodePtr[i]  =  RQNodePtr[j];  /*  switch  places  */ 
i  =  j;  /*  look  at  next  parent  */ 

j  =  2*i;  /*  and  its'  children  */ 

} 
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RQNodePtr[i]  =  save;  /*  Place  new  node  in  its  proper  place  */ 

} 

/* . Empty . */ 

emptyO  /*  test  for  an  empty  queue  */ 

{ 

int  RQempty; 
iffRQSize  ==  0) 

RQempty  =  TRUE;  /*  either  its  empty  */ 
else 

RQempty  =  FALSE;  /*  or  it  isn't  */ 

return(RQempty);  /*  return  boolean  type  answer  */ 

} 

/* . Full . */ 

fullO  /*  test  for  a  full  queue  */ 

{ 

int  RQfull; 

iflRQSize  ==  RQMAXSIZE) 

RQfull  =  TRUE;  /*  either  its  full  */ 

else 

RQfull  =  FALSE;  /*  or  it  isn't  */ 

return(RQfull);  /*  return  boolean  type  answer  */ 

} 

/* . Purge . */ 

Purge  () 

{ 

int  next, temp; 

purgeNum  =  0;  /*  initialize  number  of  jobs  purged  this  time  */ 

temp  =  RQSize;  /*  needed  for  index  */ 

for(i=l;i<=  temp;i++)  /*  Search  only  through  actual  size  of  queue  */ 

{ 

iflRQNodePtr[i]->JobNum  &  0x0400)  /*  if  job  is  purgeable  */ 

{ 

next  =  RQNodePtr[i]  -  &RQNodes[0];  /*  making  new  free  space  */ 
RQNodes[lastFree].NextFreeNode  =  next; 

lastFree  =  next;  /*  make  it  the  last  free  */ 


83 


RQNodePtr[i]  =  RQNodePtr[RQSize];  /*  Put  lowest  job  in  its  place  */ 
RQSize-=l;  /*  decrease  RQ  Size  */ 

siftdown(i);  /*  restructure  heap  */ 

} 

} 

purgeNum  =  temp  -  RQSize;  /*  how  many  jobs  were  purged?  */ 

} 


*****************  SCHEDULE  C  ***************** 


/*  Schedule. c  contains  the  routines  for  the  Cycle  Interrupt  Handler  */ 
/*  and  the  scheduler.  */ 


#include  "A-linetest.h"  /*  include  global  variables  */ 

*/ 
*/ 
*/ 
*/ 

doScheduleO 

( 

#asm 

XREF  Schedule,  CTP 


/*  doSchedule  is  also  known  as  the  Cycle  Interrupt  Handler. 
/*  This  piece  of  code  is  the  beginning  of  every  new  frame. 

/*  On  the  Macintosh,  this  routine  is  in  the  level  0  interrupt 
/*  table  which  is  shared  by  several  other  devices. 


MOVE 

MOVE.L 

MOVEM.L 

MOVE.L 

BTST 

BNE 

JMP 


#$2700, SR 

RQNodePtr+4(A5),A0 

D0-D7/A0-A7,l  2(A0) 

01dJob(A5),Al 

#6,$EFFBFE 

timerl 

(Al) 


;  inhibit  interrupts 
;  get  current  job  info 
;  store  current  registers 

;  is  it  timer  1? 

;  yes  do  it 

;  OldJob  is  an  Apple  routine 


timerl : 

MOVE.W 

OR 

MOVE.W 

JSR 

JSR 

JMP 

RTS 

#endasm 


(AO), DO 
#$0800, DO 
DO, (A0) 
Purge 
Schedule 
CTP 


get  top  job  number 
Set  rupt  bit 

put  new  job  num  back 
clean  out  Queue 
schedule  new  frame  tasks 


} 

ScheduleO  /*  routine  to  schedule  jobs  */ 

{ 
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if(RQSize  ==  RQMAXSIZE) 
return; 


/*  Would  normally  trip  an  alarm  */ 


JobMask2  =  (FrameCounter  &  1);  /*  calculate  job  masks  for  those  tasks  */ 

JobMask4  =  (FrameCounter  &  3);  /*  which  are  not  scheduled  every  frame  */ 
JobMask8  =  (FrameCounter  &  7); 


for(i=0;  i<MAXEVERYl;  i++)  /*  enqueue  those  that  are  scheduled  */ 
enqueue(EverylTime[i]);  /*  every  frame  */ 


for(i=JobMask2;  i<MAXEVERY2;  i+=2) 
enqueue(Every2Time[i]); 

for(i=JobMask4;  i<MAXEVERY4;  i+=4) 
enqueue(Every4Time[i]); 

for(i=JobMask8;  i<MAXEVERY8;  i+=8) 
enqueue(Every8Time[i]); 

FrameCounter  +=  1; 

} 


/*  enqueue  those  that  are  */ 

/*  scheduled  every  other  frame  */ 

/*  enqueue  those  that  are  */ 

/*  scheduled  every  fourth  frame  */ 

/*  enqueue  those  that  are  */ 

/*  scheduled  every  eighth  frame*/ 

/*  increment  frame  counter  */ 


****************5*:^  LINES  C  ***************** 


/*  A-Line  Trap  Handler  */ 

#include  ”A-linetest.h"  /*  Include  file  for  global  variables  and  defs  */ 


/*  InitALine  actually  replaces  the  F-Line  Trap  Handler  on  the  Macintosh*/ 
/*  The  A-Line  Trap  is  used  on  the  Macintosh,  however  the  end  result  is  */ 

/*  the  same  as  they  are  both  unimplemented  instructions.  */ 

InitALineO 

{ 

#asm 

MOVE.L 
LEA 
MOVE.L 

#endasm 

} 


$2C,MacTraps(A5)  ;  Save  old  A-Line  Handler 

ALines,A0  ;  Load  Trap  Handling  Routine 

A0,$2C 


/*  This  is  the  actual  routine  vectored  to  ater  the  execution  of  a  trap  */ 
/*  Since  there  will  never  be  an  RTE  from  this  routine  the  stack  must  */ 
/*  be  adjusted  prior  to  leaving  the  routine.  */ 
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ALinesO 

{ 


/*  A-Line  Trap  Handling  Routine  */ 


#asm 

XREF  Dispatch 


MOVE 
MOVE AX 
MOVE.W 
ADDQX 
ANDLL 
MOVE.W 
JMP 
#endasm 


#$2700, SR  ; 

$02(A7),A2  ; 

(A2),D2 

#$6,A7  ; 

#$03FF,D2  ; 

D2,PresentJob(A5) ; 
Dispatch  ; 


insure  no  interruptsrupts 
fetch  PC  and  its  contents 
Store  trap  in  D2 
adjust  stack 

get  last  10  bits  of  word-job  number 
store  job  number  for  dispatch  table 
go  to  dispatch  table 


} 


/*  The  Dispatch  Table  is  where  the  actual  Job  is  vectored  to.  */ 
/*  The  job  also  will  return  here  upon  completion.  */ 


DispatchO 

{ 


/*  job  dispatch  table  */ 

/*  limited  number  of  jobs  version  */ 


switch(PresentJob) 

{ 


/*  based  on  job  from  A-Line  Trap  Handler  */ 


} 


case  1: 

JoblO; 

JobDoneO; 

break; 

/  *  handle  Job  1  */ 

/*  After  Job  is  completed  */ 

case  2: 

Job2(); 

JobDoneO; 

break; 

/  *  handle  Job  2  */ 

/*  After  Job  is  completed  */ 

case  3: 

monitorO; 

break; 

/  *  handle  Job  1  */ 

/*  Monitor  is  never  completed  */ 

default: 

JobDO; 

JobDoneO; 

/  *  handle  all  the  other  jobs  */ 

/*  After  Job  is  completed  */ 

break; 
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/*  The  JobDone  routine  is  responsible  for  removing  the  job  from  the  */ 
/*  ready  queue  by  calling  the  Serve  function.  This  routine  should  not  */ 
/*  be  interrupted.  Control  is  passed  on  to  the  CTP  after  completion.  */ 


JobDoneO 

{ 

if  o  c  m 

XREF  CTP, Serve 

;  inhibit  interrupts  until  done 
;  Remove  top  job  from  ready  queue 
;  adjust  stack  since  there  is  no  RTS 
;  Go  back  to  CTP  for  next  job 


} 


MOVE  #$2700, SR 

JSR  Serve 

ADDQ.L  #$4,A7 
JMP  CTP 

#endasm 


/*  The  following  are  small  sample  jobs  used  to  test  the  OS  */ 

JoblO 

{ 

#asm 

MOVE  #$2000, SR  ;  required  of  all  jobs  written 

MOVE.B  $EFE9FE,$FFCF7  ;  read  6522  timer  count  lower  byte 

MOVE.B  $EFEBFE ,$FFCF6  ;  read  6522  timer  count  HIGHER  byte 

#endasm 

} 


Job2() 

{ 

#asm 

MOVE  #$2000, SR  ;  required  of  all  jobs  written 

MOVE.B  $EFE9FE,$FFCF9  ;  read  6522  timer  count  lower  byte 

MOVE.B  $EFEBFE,$FFCF8  ;  read  6522  timer  count  HIGHER  byte 

#endasm 

} 


JobDO 

( 

/*  NULL  Job  */ 

} 
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APPENDIX  B 


SOURCE  CODE  LISTSINGS  FOR  A  PARTIAL  MONITOR 

This  Appendix  contains  the  source  code  modules  for  a  partial 
monitor.  The  monitor  was  used  as  a  low  level  job  to  test  the  operating 
system.  It  is  a  partial  monitor  in  that  it  can  only  do  memory  display  and 
memory  modify.  A  full  function  monitor  should  aslo  be  able  to  display  and 
modify  registers,  set  breakpoints  and  allow  the  running  of  another 
program  using  a  "Go"  routine.  All  the  functions  which  were  not 
implemented  are  located  in  a  stub  module  to  complete  the  linking  process. 
This  should  make  the  further  refinement  of  the  program  easier  as  well. 

The  listings  start  with  the  Main  module  which  is  the  entry  point  into 
the  monitor.  The  monitor  was  written  in  C  to  maintain  portability.  The  C 
programming  language  was  commented  as  much  as  possible  to  enhance 
readability.  The  modules  are  presented  in  the  approximate  order  in  which 
they  are  used. 
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MONITOR.H  monitor  header  file 


/* 


*/ 


#define 

CONTINUE 

1 

#define 

HEX  ERR 

2 

#define 

MODIFY 

3 

#define 

BS 

0x08 

#define 

CR 

OxOD 

#define 

NULL 

0x00 

#defme 

SPACE 

0x20 

/*  CONTINUATION  FLAG  */ 

/*  HEX  CONVERSION  ERROR  */ 

/*  MEMORY  MODIFY  FLAG  */ 

/*  ASCII  CODE  FOR  BACKSPACE  */ 
/*  ACCII  CODE  FOR  RETURN  */ 

/*  ASCII  CODE  FOR  NULL  */ 

/*  ASCII  CODE  FOR  SPACE  */ 


#ifdef  MAINMON 


char  BUFFIN[255];  /*  255  char  input  buffer  */ 
int  COUNT; 

char  MONSTAT[3];  /*  RESERVE  3  BYTES  FOR  STATUS  */ 
long  START.ADDRESS 

long  END.ADDRESS;  /*  RESERVE  LONG  WORDS  FOR  ADDRESSES  */ 
long  DATA;  /*  DATA  FOR  MEM  MODIFY  */ 


/*  messages  */ 

char  *BKPTMSG  =  "BREAKPOINT  TRAP  AT 

char  *ERRMSG  =  "ERROR  RE-ENTER"; 

char  *HEXMSG  =  "HEX  CONVERSION  ERROR. ..RE-ENTER"; 

char  *ILLMSG  =  "ILLEGAL  INSTRUCTION  TRAP"; 

char  *MONMSG  =  "68000  MONITOR  VO.OXrWRITTEN  IN  C  BY  BOB 

VOIGTXr"; 

char  *REGERR  =  "REGISTER  CONTENTS  ERROR  RE-ENTER"; 


char  ^commands!  ]  =  /*  command  string  */ 

{"BKPT","RCHG","NOBK","REGl","QUIT","NL", 
"BK","GO","MD","MM"}; 


#else 

extern 

char 

BUFFINf  ],MONSTAT[  ]; 

extern 

int 

COUNT; 

extern 

long 

BKPTABf  ], START  ADDRESS, END  ADDRESS; 

extern 

long 

DATA; 

extern 

char 

*BKPTMSG,*ERRMSG,*HEXMSG; 

extern 

char 

*ILLMSG,*MONMSG; 

extern 

#endif 

char 

*REGERR,*REGMSG[  ],*commands[]; 
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/* . MAIN . 

/*  MAIN  IS  THE  ENTRY  POINT  INTO  THE  MONITOR. 


-  */ 
*/ 


#define  MAINMON 

#include  "monitor. h"  /*  include  header  file  */ 

monitorO 

{ 

for(i=0;  i<8;i++) 

MONSTAT[i]  =  0;  /*  Clear  Monitor  Status  */ 

MESSAGE(MONMSG);  /*  Output  opening  message  */ 

while(TRUE) 

{ 

printf("\r$  ");  /*  Print  Prompt  "$"  */ 

gets(BUFFIN);  /*  Enter  monitor  */ 

putchar(CR); 

CMD_DECODE();  /*  Decode  input  */ 

} 

}  /*  end  main  */ 

/* . CMD_DECODE .  */ 

/*  THIS  PROGRAM  DECODES  COMMANDS  */ 

/*  FROM  THE  COMMAND  LINE  */ 

CMD_DECODE() 

{ 

char  match; 

for(i=0;i<4;i++)  /*  Convert  all  input  commands  to  upper  case  */ 

BUFFIN[i]  =  toupper(BUFFIN[i]); 

for(i=0;i<5;i++)  /*  look  for  4  letter  commands  first  */ 

{ 

match  =  strncmp(BUFFIN,commands[i],4); 

/*  C  function  comparing  first  4  letters  of  command  string  */ 
iflmatch  ==  0) 

{ 

switch(i)  /*  if  there's  a  match  go  to  that  routine  */ 

{ 

case  0:  /*  case  numbers  are  indices  of  command  string  */ 

BKPTO; 

break; 
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case  1 : 

REGCHANGO; 

break; 

case  2: 

NO.BKPTO; 

break; 

case  3: 

REGIO; 

break; 

case  4: 

ExitToShellO;  /*  QUIT  */ 
break; 


} 

break; 

} 

} 

if(match  !=  0) 

{ 

for(i=5;i<10;i++) 

{ 


/*  end  switch  */ 

/*  end  if  strncmp  */ 

/*  end  for  */ 

/*  if  no  match  in  4  letters  */ 

/*  try  two  letter  commands  */ 


match  =  strncmp(BUFFIN,commands[i],2); 


iflmatch  ==  0) 

{ 

switch(i) 

( 

case  5: 

NL(); 

break; 

case  6: 

BKPT_LIST(); 

break; 


case  7: 

GOO; 

break; 


case  8: 

MEM_DISPLAY(); 

break; 
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Start_ADD[i]  =  BUFFIN[j]; 

i++; 

j++'> 


/*  get  string  representation  */ 


} 

sscanflStart_ADD,"%X",&START_ADDRESS); 


iflBUFFIN[j]  ==  NULL) 
return; 

i  =  0; 
j++; 

while(BUFFIN[j]  !=  NULL) 

{ 

ifl!ishex(BUFFIN[j])) 

{ 

MESSAGE(HEXMSG); 
MONSTAT[HEX_ERR]  =  TRUE; 
return; 

} 

End_ADD[i]  =  BUFFINIj]; 
i++; 

j++; 

} 

iftMONSTAT[MODIFY]) 


/*  convert  string  to  hex  */ 
/*  exit  with  return  address  =  0  */ 

/*  string  is  terminated  by  a  NULL  */ 

/*  check  for  proper  hex  format  */ 

/*  not  proper  format  */ 

/*  exit  with  error  message  */ 

/*  get  string  representation  of  data  */ 

/*  if  modify  -  convert  to  data  */ 


sscanf(End_ADD,,,%X",&DATA); 
else  /*  else  convert  end  address  */ 

sscanflEnd_ADD,"%X",&END_ADDRESS); 

}  /*  end  get_addr  */ 


ishex(c)  /*  routine  to  check  ifO<c<F  -  a  hex  number  */ 
char  c; 

{ 

if((c  >=  ’a’  &&  c<=  T )  I  I  (c  >=  'A'  &&  c<=  'F')  I  I  isdigit(c)) 
return(TRUE); 
else 

return(FALSE);  /*  returns  a  boolean  true  or  false  */ 

} 

/* .  MEM.MODIFY -  */ 

/*  THIS  PROGRAM  MODIFIES  THE  CONTENTS  OF  */ 
/*  THE  SPECIFIED  MEMORY  LOCATIONS  */ 
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MEM_MODIFY() 

( 

MONSTAT[MODIFY]  =  TRUE;  /*  Set  modify  flag  */ 
MEM_DISPLAY();  /*  Display  memory  */ 

MONSTAT[MODIFY]  =  FALSE;  /*  Clear  modify  flag  */ 

} 

/* .  MEM_DISPLAY .  */ 

/*  THIS  PROGRAM  DISPLAYS  THE  CONTENTS  OF  */ 

/*  THE  SPECIFIED  MEMORY  LOCATIONS  */ 

MEM_DISPLAY() 

{ 

unsigned  char  *byte,*databyte,*address,c; 
long  *temp; 

MON  ST  AT[HEX_E  RR]  =  FALSE;  /*  Clear  errors  */ 

GET_ADDR();  /*  Convert  address  to  hex  */ 

if(MONSTAT[HEX_ERR])  /*  Was  there  a  hex  error  ?  */ 

return;  /*  yes,  so  exit  */ 

/*  make  starting  address  a  pointer  to  a  byte  */ 
byte  =  (unsigned  char  *)START_ADDRESS; 

if  (END_AD DRESS  ==  0)  /*  if  no  end  address  then  just  list  one  row  */ 

END_ADDRESS  =  START_ADDRESS; 

if(MONSTAT[MODIFY])  /*  if  modifying  data  */ 

{ 

databyte  =  (unsigned  char  *)&DATA;  /*  data  */ 

address  =  byte;  /*  use  dummy  variables  */ 

for  (i=0;i<4;i++) 

{ 

if((*databyte  &&  OxFF)  !=  0) 

*address++  =  *databyte++; 
else 

*databyte++; 

} 

} 

/*  display  address  with  changes  */ 

for(j=START_ADDRESS;  j<=  END_AD  DRESS;  j+=0xl0) 

{ 

iflKeyReadyO)  /*  MAC  specific  routines  */ 

{ 
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c  =  inKeyO;  /*  a  backspace  can  stop  the  display  */ 

if(c  ==  BS) 
return; 

} 


printft"\r%-8X  "  j);  /*  print  start  address  for  the  row  */ 


for(i=0;i<8;i++) 

{ 

if(*byte  ==  0) 

{ 

printfTOO"); 

*byte++; 


/*  print  8  groups  of  4  bytes  with  spaces  between  */ 

/*  if  whole  byte  is  zero  -  print  zeros  */ 

/*  need  to  fill  in  zeros  with  real  zeros  on  screen  */ 

/*  get  next  byte  */ 


1 

else 

{ 

if((*byte  &  OxOOFO)  ==  0) 
printfT'O"); 

printfT'%lX",*byte++); 


/*  only  upper  nibble  is  a  zero  */ 
/*  print  contents  of  byte  */ 


} 


if(*byte  ==  0)  /*  if  whole  byte  is  zero  -  print  zeros  */ 

{ 

printfTOO  ");  /*  these  zeros  have  a  space  after  them  -  formatted  */ 

*byte++;  /*  get  next  byte  */ 

} 

else 

{ 

ifl(*byte  &  OxOOFO)  ==  0)  /*  if  upper  nibble  is  zero  again  */ 

printfTO"); 

printfT%lX  ",*byte++);  /*  print  byte  with  a  space  after  it  */ 

} 

} 

} 

}  /*  end  MEM_DISPLAY  */ 

/* . OUTPUT_BYTE . */ 

/*  THIS  PROCEDURE  CONVERTS  A  BYTE  INTO  2  ASCII  */ 

/*  CHARACTERS  AND  SENDS  THE  CHARACTERS  TO  */ 

/*  THE  CRT  DISPLAY  */ 


OUTPUT_BYTE(byte) 
char  byte 
{ 

printf("%2X",byte);  /*  convert  and  print  */ 

} 
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/*-- . MESSAGE . */ 

/*  THIS  PROCEDURE  OUTPUTS  MESSAGES  TO  THE  CRT  SCREEN  */ 

MESSAGE(msgout) 

char  *msgout; 

{ 

printfC  %s",msgout);  /*  output  message  */ 

iffmsgout  ==  ERRMSG)  /*  if  there  was  a  problem  with  the  input  */ 

{ 

printfC \rCOMMANDS  ARE:\r");  /*  remind  user  of  proper  commands  */ 
for(i=0;i<10;i++) 

printfC  '%s  ",commands[i]); 

} 

} 


/* - STUBS - */ 

/*  THIS  FILE  CONTAINS  PROGRAMMING  STUBS  */ 

BKPT_LIST() 

{ 

printfC'in  BKPT_LIST\r"); 

} 

NO_BKPT() 

{ 

printfC'in  NO_BKPT\r"); 

} 

GOO 

{ 

printfC'in  GO\r"); 

} 


REGCHANGO 

{ 

printfC'in  REGCHANGNr"); 

} 

REG10 

{ 

printfC’in  REGl\r"); 

} 

BKPTO 

{ 

printfC'in  BKPTNr"); 

} 
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APPENDIX  C 

THE  HARDWARE  ENVIRONMENT 


The  operating  system  design  was  implemented  on  an  Apple  Macintosh 
personal  computer.  The  operating  system  ran  on  the  Apple  Macintosh 
computer  essentially  as  an  application  under  the  Macintosh's  operating 
system.  It  did  not  take  full  control  of  the  system,  however  it  did  modify  the 
Macintosh's  vector  tables. 

The  Macintosh  is  not  a  DOS  based  computer.  The  Macintosh  operating 
system  is  ROM  based  and  the  operating  system  kernel  routines  are  in 
ROM.  It  contains  a  unique  input/output  setup  and  is  by  no  means  a 
development  station  for  an  imbedded  MC68000  system. 

Figure  C.l  is  a  block  diagram  of  the  main  logic  board  of  the  Macintosh. 
The  Macintosh  uses  a  great  deal  of  Programmable  Array  Logic  (PALS). 
The  PALS,  which  are  proprietary,  may  have  a  great  deal  to  do  with  the 
operating  speed  of  the  Macintosh  and  contribute  to  the  Macintosh  not  being 
an  optimal  system  for  a  real  time  development  station. 
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Figure  C.l  Macintosh  ™  Logic  Board  Block  Diagram 


APPENDIX  D 


READY  QUEUE  PERFORMANCE  DATA 

The  following  data  was  recorded  using  the  SY6522  timer.  The 
execution  times  shown  are  the  times  necessary  for  the  Scheduler  to 
schedule  eight  jobs  per  minor  cycle  until  the  queue  is  full.  The  maximum 
jobs  the  queue  could  hold  was  fifty.  The  time  was  measured  in  E-Clock 
cycles,  the  E-Clock  runs  at  0.9792  MHz. 


Number  of  Times 

Schedule  Called 

Run  1 

E-Clocks 

Run  2 

Run  3 

1 

2252 

2241 

2255 

2 

2392 

2565 

2392 

3 

2432 

2389 

2435 

4 

2599 

2644 

2556 

5 

2447 

2675 

2436 

6 

2478 

2603 

2476 

7 

1001 

1001 

999 

The  following  data  measurements  are  for  the  Serve  routine.  The  data 
was  acquired  by  starting  with  a  full  queue  and  serving  one  element  at  a 
time  until  the  queue  was  empty. 


Number  of  Elements 
in  Queue  Before  Serve 

50 

49 

48 

47 

46 

45 

44 

43 

42 


Time  to  Serve 
in  ms 

0.561 

0.534 

0.546 

0.649 

0.549 

0.543 

0.523 

0.564 

0.559 
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of  Elements 

Time  to  Serve 

Before  Serve 

in  ms 

41 

0.556 

40 

0.545 

39 

0.544 

38 

0.551 

37 

0.543 

36 

0.548 

35 

0.526 

34 

0.550 

33 

0.523 

32 

0.444 

31 

0.458 

30 

0.451 

29 

0.469 

28 

0.543 

27 

0.438 

26 

0.455 

25 

0.460 

24 

0.453 

23 

0.463 

22 

0.361 

21 

0.438 

20 

0.448 

19 

0.364 

18 

0.426 

17 

0.419 

16 

0.383 

15 

0.420 

14 

0.359 

13 

0.352 

12 

0.304 

11 

0.355 

10 

0.312 

9 

0.349 

8 

0.362 

7 

0.273 

6 

0.324 

5 

0.269 

4 

0.238 

3 

0.202 

2 

0.165 

1 

0.170 

99 


LIST  OF  REFERENCES 


1.  National  Aeronautics  and  Space  Administration  Technical 
Memorandum  72860,  Digital  Flv-Bv-Wire  FlightControl  Validation 
Experience,  by  Kenneth  J.  Szalai,  Calvin  R.  Jarvis,  Vincent  A.  Megna, 
Larry  D.  Brock,  and  Robert  N.  O'Donnell,  December  1978. 

2.  National  Aeronautics  and  Space  Administration  CR-163117,  Advanced 
Flight  Control  System  Study,  by  G.  L.  Hartmann,  J.  E.  Hall,  Jr.,  E.  R. 
Rang,  H.  P.  Lee,  R.  W.  Schulte,  and  W.  K.  Ng,  November  1982. 

3.  Dijkstra  E.W.,  "The  structure  of  T.H.E  Multiprogramming  System," 
Communications  of  the  ACM.  Vol  11,  No.  5,  May  1968. 

4.  Deitel,  Harvey  M.,  Operating  Systems.  Addison-Wesley  Publishing 
Company,  Inc.,  1984. 

5.  Stubbs,  Daniel  F.  and  Webre,  Neil  W.,  Data  Structures  with  Abstract 
Data  Types  and  Pascal.  Brooks/Cole  Publishing  Company,  1985. 

6.  Kernighan,  Grian  W.  and  Ritchie,  Dennis  M.,  The  C  Programming 
Language  Prentice-Hall,  Inc.,  1978. 

7.  M68000  8-/16-/32-Bit  Microprocessors  Programmer's  Reference  Manual. 

fifth  edition,  Prentice-Hall,  Inc.,  1986. 


100 


BIBLIOGRAPHY 


Charles  Stark  Draper  Laboratory  CSDL-P-1727,  Fault  Tolerant 
Processor  Concepts  and  Operation,  by  Basil  T.  Smith,  1  May  1983. 

Freedman,  A.  L.  and  Lees,  R.A.,  Real-Time  Computing  Systems. 
Crane,  Russak  and  Company,  Inc.,  1977. 

Inside  Macintosh.  Volumes  I, II, III,  and  IV,  Addison-Wesley 
Publishing  Company,  Inc.,  1985. 

Knuth,  Donald  E.,  The  Art  of  Computer  Programming.  Volume  3. 
Searching  and  Sorting.  Addison-Wesley  Publishing  Company,  Inc., 
1973. 

Liebowitz,  Burt  H.  and  Carson,  John  H.,  Multiple  Processor  Systems 
for  Real-Time  Applications.  Prentice-Hall,  Inc.,  1985. 

NCR  Microelectronics,  NCR  Microelectronics  Data  Book.  1985. 

Shaw,  Alan  C.,  The  Logical  Design  of  Operating  Systems.  Prentice- 
Hall,  Inc.,  1985. 

Tsichritzis,  Dionysios  C.  and  Bernstein,  Philip  A.,  Operating  Systems. 
Academic  Press,  Inc.,  1974. 


101 


s 


f>  Y  f)  n  f 


INITIAL  DISTRIBUTION  LIST 


No.  Copies 


1.  Defense  Technical  Information  Center  2 

Cameron  Station 

Alexandria  Virginia  22304-6145 

2.  Library,  Code  0142  2 

Naval  Postgraduate  School 

Monterey,  California  93943-5002 

3.  Department  Chairman,  Code  62  1 

Department  of  Electrical  and  Computer  Engineering 

Naval  Postgraduate  School 
Monterey,  California  93943-5000 

4.  Professor  Larry  W.  Abbott,  Code  62  At  1 

Department  of  Electrical  and  Computer  Engineering 

Naval  Postgraduate  School 
Monterey,  California  93943-5000 

5.  Professor  Sherif  Michael,  Code  62  Mi  1 


Department  of  Electrical  and  Computer  Engineering 
Naval  Postgraduate  School 
Monterey,  California  93943-5000 

6.  Commanding  Officer  1 

Attn:  LT  Robert  J.  Voigt 
Naval  Underwater  Systems  Center 
Naval  Education  and  Training  Center 
Newport,  Rhode  Island  02841-5000 


102 

1  80  TO 


2 


1 


DUDLEY  KI'OX  LIBRARY 

vm™*?  cn RADr/ATE  SCHOOL 
ONTERE/,  CALIPORiTIA  92943-6002 


Thesis 

V855  Voigt 

c.l  The  design  of  a  real 

time  operating  system  for 
a  fault  tolerant  micro¬ 
computer. 


Thesis 
V855 
c.  1 


Voigt 

The  design  of  a  re=>l 
time  operating  system  for 
fault  tolerant  micro- 
computer • 


thesV855 

The  design  of  a  real  time  operating  syst 


3  2768  000  71062  8 

DUDLEY  KNOX  LIBRARY 


